構建模塊

 

服務(wù)器和客戶(hù)端

 

OTA更新用新軟件替換器件上的當前軟件，新軟件以無(wú)線(xiàn)方式下載。在嵌入式系統中，運行此軟件的器件通常是微控制器。微控制器是一種小型計算器件，其存儲器、速度和功耗均很有限。微控制器通常包含微處理器（核心）和用于執行特定操作的數字硬件模塊（外設）。工作模式下典型功耗為30μA/MHz至40μA/MHz的超低功耗微控制器是此類(lèi)應用的理想選擇。使用這些微控制器上的特定硬件外設并將其置于低功耗模式，是OTA更新軟件設計的重要組成部分。圖1顯示了一個(gè)可能需要OTA更新的嵌入式系統實(shí)例?？梢钥吹?，一個(gè)微控制器與無(wú)線(xiàn)電和傳感器相連，這可用在物聯(lián)網(wǎng)應用中，利用傳感器收集有關(guān)環(huán)境的數據，并利用無(wú)線(xiàn)電定期報告數據。系統的這一部分稱(chēng)為邊緣節點(diǎn)或客戶(hù)端，是OTA更新的目標。系統的另一部分稱(chēng)為云或服務(wù)器，是新軟件的提供者。服務(wù)器和客戶(hù)端利用收發(fā)器（無(wú)線(xiàn)電）通過(guò)無(wú)線(xiàn)連接進(jìn)行通信。

 

圖1.示例嵌入式系統中的服務(wù)器/客戶(hù)端架構

 

何為軟件應用程序？

 

OTA更新過(guò)程的大部分操作是將新軟件從服務(wù)器傳輸到客戶(hù)端。軟件從源格式轉換為二進(jìn)制格式之后，作為一個(gè)字節序列進(jìn)行傳輸。轉換過(guò)程會(huì )編譯源代碼文件（例如c、cpp），將其鏈接成一個(gè)可執行文件（例如exe、elf），然后將可執行文件轉換為可移植的二進(jìn)制文件格式（例如bin、hex）。概言之，這些文件格式包含一個(gè)字節序列，此字節序列屬于微控制器中存儲器的特定地址。通常，我們將通過(guò)無(wú)線(xiàn)鏈路發(fā)送的信息概念化為數據，例如更改系統狀態(tài)的命令或系統收集的傳感器數據。就OTA更新而言，數據就是二進(jìn)制格式的新軟件。在很多情況下，二進(jìn)制文件非常大，無(wú)法通過(guò)單次傳輸從服務(wù)器發(fā)送到客戶(hù)端，這意味著(zhù)需要將二進(jìn)制文件放入多個(gè)不同的數據包中，此過(guò)程稱(chēng)為“分包”。為了更好地說(shuō)明此過(guò)程，圖2演示了軟件的不同版本如何生成不同的二進(jìn)制文件，從而在OTA更新期間發(fā)送不同的數據包。在這個(gè)簡(jiǎn)單例子中，每個(gè)數據包包含8字節數據，前4個(gè)字節表示客戶(hù)端存儲器中用來(lái)存儲后4個(gè)字節的地址。

 

主要挑戰

 

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

 

圖2.軟件應用程序的二進(jìn)制轉換和分包過(guò)程

 

第二階段引導加載程序(SSBL)

 

了解引導序列

 

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

 

經(jīng)驗教訓：務(wù)必有一個(gè)SSBL

 

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

 

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

 

●     許多嵌入式軟件應用程序采用實(shí)時(shí)操作系統(RTOS)，其允許將軟件拆分為多個(gè)并發(fā)任務(wù)，每個(gè)任務(wù)在系統中具有不同的職責。例如，圖1所示的應用程序可能有用于讀取傳感器的RTOS任務(wù)，對傳感器數據運行某種算法的RTOS任務(wù)，以及與無(wú)線(xiàn)電接口的RTOS任務(wù)。RTOS本身始終處于活動(dòng)狀態(tài)，負責根據異步事件或特定的基于時(shí)間的延遲切換這些任務(wù)。因此，從RTOS任務(wù)分支到新程序是不安全的，因為其他任務(wù)會(huì )在后臺繼續運行。對于實(shí)時(shí)操作系統，終止某個(gè)程序的唯一安全方法是通過(guò)復位。

 

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

 

圖4.沒(méi)有SSBL的存儲器映射和引導流程示例

 

●     基于圖4，上述問(wèn)題的解決辦法是讓主引導加載程序分支到應用程序B而不是應用程序A。但在某些微控制器上，主引導加載程序總是運行具有中斷向量表(IVT)的程序；IVT是應用程序的一個(gè)關(guān)鍵部分，描述中斷處理函數，位于地址0。這意味著(zhù)必須以某種形式重定位IVT，使其復位映射到應用程序B。如果在IVT重定位期間發(fā)生斷電重啟，則系統可能會(huì )處于永久破損狀態(tài)。

 

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

 

設計權衡：SSBL的作用

 

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

 

設計權衡：緩存和壓縮

 

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

 

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

 

新應用軟件屬于閃存，但在更新過(guò)程中到達SRAM，因此OTA更新軟件需要在更新過(guò)程中的某個(gè)時(shí)刻執行對閃存的寫(xiě)操作。暫時(shí)將新應用程序存儲在SRAM中的操作稱(chēng)為緩存。概言之，OTA更新軟件可以采取三種不同的緩存方法。

 

●     不緩存：每次包含新應用程序一部分的數據包到達時(shí)，便將其寫(xiě)入閃存中的目標位置。這種方案非常簡(jiǎn)單，可以最大限度地減少OTA更新軟件中的邏輯數量，但要求完全擦除新應用程序對應的閃存區域。此方法會(huì )消磨閃存并增加開(kāi)銷(xiāo)。

 

●     部分緩存：保留一個(gè)SRAM區域用于緩存，當新數據包到達時(shí)，將其存儲在該區域中。當該區域填滿(mǎn)時(shí)，將數據寫(xiě)入閃存以清空該區域。如果數據包無(wú)序到達或新應用程序二進(jìn)制文件中存在間隙，這種方案可能會(huì )變得很復雜，因為需要一種方法來(lái)將SRAM地址映射到閃存地址。一種策略是讓緩存充當閃存一部分的鏡像。閃存被劃分為若干稱(chēng)為頁(yè)面的小區域，這是可供擦除的最小區域。得益于這種自然劃分，一個(gè)好辦法是在SRAM中緩存閃存的一頁(yè)，當其填滿(mǎn)或下一數據包屬于其他頁(yè)面時(shí)，便將該頁(yè)寫(xiě)入閃存以清空緩存。

 

●     完全緩存：在OTA更新過(guò)程中將整個(gè)新應用程序存儲在SRAM中，只有從服務(wù)器完全下載好新應用程序之后才將其寫(xiě)入閃存。這種方法克服了前述方法的缺點(diǎn)，寫(xiě)入閃存的次數最少，OTA更新軟件無(wú)需復雜的緩存邏輯。但是，這會(huì )限制所下載新應用程序的大小，因為系統的可用SRAM量通常遠小于可用閃存量。

 

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

 

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

 

安全和通信

 

設計權衡：軟件與協(xié)議

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

 

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

 

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

 

解決安全挑戰

 

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

 

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

 

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

 

圖7.使用非對稱(chēng)加密驗證消息

 

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

 

哈希鏈將本節討論的加密概念整合到一系列數據包中，以便在數學(xué)上將它們聯(lián)系在一起。如圖8所示，第一個(gè)數據包（編號0）包含下一個(gè)數據包的摘要。第一個(gè)數據包的有效載荷不是實(shí)際的軟件應用程序數據，而是簽名。第二個(gè)數據包（編號1）的有效載荷包含二進(jìn)制文件的一部分和第三個(gè)數據包（編號2）的摘要?？蛻?hù)端驗證第一個(gè)數據包中的簽名并緩存摘要H0以供以后使用。當第二個(gè)數據包到達時(shí)，客戶(hù)端對有效載荷進(jìn)行哈希處理并將其與H0進(jìn)行比較。如果它們匹配，客戶(hù)端便可確定該后續數據包來(lái)自可信服務(wù)器，而無(wú)需費力進(jìn)行簽名檢查。生成此鏈的高開(kāi)銷(xiāo)任務(wù)留給服務(wù)器完成，客戶(hù)端只需在每個(gè)數據包到達時(shí)進(jìn)行緩存和哈希處理，確保到達的數據包完整無(wú)損并驗明正身。

 

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

 

實(shí)驗設置

 

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

 

硬件配置

 

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

 

圖9.實(shí)驗硬件設置

 

軟件組件

 

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

 

圖10.客戶(hù)端軟件架構

 

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

 

●     緩存：根據用戶(hù)配置，支持不緩存或緩存閃存的一頁(yè)。

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

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

 

結果

 

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

 

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

 

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

 

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

 

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

 

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

 

這些結果證明，設計決策對軟件性能會(huì )有切實(shí)的影響。不存在一個(gè)萬(wàn)能的解決方案，每個(gè)系統都有不同的要求和約束，OTA更新軟件需要視具體情況具體對待。希望本文闡明了在設計、實(shí)現和驗證OTA更新軟件解決方案時(shí)遇到的常見(jiàn)問(wèn)題和權衡。

 

參考文獻

 

Nilsson、Dennis Kengo和Ulf E. Larson。“智能車(chē)輛的無(wú)線(xiàn)安全固件更新”。ICC研討會(huì )——2008年IEEE國際通信會(huì )議，2008年5月。

 

Benjamin Bucklin Brown

 

Benjamin Bucklin Brown [benjamin-b.brown@analog.com]于2016年從麥吉爾大學(xué)畢業(yè)并獲得電氣工程學(xué)士學(xué)位后加入ADI公司。目前他在消費電子檢測與處理技術(shù)(CSPT)部門(mén)工作，擔任嵌入式軟件工程師，為專(zhuān)用集成電路開(kāi)發(fā)固件。此前，他曾在物聯(lián)網(wǎng)平臺技術(shù)部門(mén)工作，為ADuCM3029和ADuCM4050微控制器開(kāi)發(fā)器件驅動(dòng)程序和軟件參考應用程序。

 

 

推薦閱讀：