基于ZigBee協議OTA技術的改進方法研究

2014-12-13 08:23:32樓亮亮周苗何為鮑星合谷宇章

現代電子技術 2014年23期

樓亮亮+周苗+何為+鮑星合+谷宇章

摘? 要：選擇TI的Zstack作為研究基礎，在ZigBee的OTA技術基礎上做了一定的改進，設計出一種多點并發、可靠、高效、低能耗的無線下載解決方案。采用數據壓縮技術實現對固件代碼數據的壓縮處理，提高了該方案的性能，并在基于CC2530傳感節點上做了具體的實現。該方案成功地應用于一個具有200多個傳感節點的ZigBee網絡中，方案的可靠性及穩定性得到了驗證。

關鍵詞： ZigBee； OTA；數據壓縮； CRC32

中圖分類號： TN921?34??????????????????????? 文獻標識碼： A??????????????????????? 文章編號： 1004?373X（2014）23?0001?04

Abstract： TI′s Zstack was selected as a research base， which improved on the basis of OTA technology established by ZigBee Alliance. A multi?concurrent， reliable， efficient， low?power OTA solution was designed. also The data compression technology is used in this solution to compress the firmware code data， so as to improve the performance of the application. It was implemented on CC2530 sensing nodes， and was applied to ZigBee network with more than 200 sensor nodes successfully. The reliability and stability of the solution were validated.

Keywords： ZigBee； OTA； data compression； CRC32

0? 引? 言

TI根據ZigBee的相關OTA標準[1]標準編寫了相應實現代碼，但是對功耗方面關注度比較少，而且必須要配合TI的軟件才能實現升級。國內針對OTA技術已有相關研究，文獻[2]涉及無線傳感網絡空中下載協議，該協議是一種具有數據傳輸、節點狀態控制功能的應用層協議，為無線傳感器網絡提供無線傳感器節點狀態控制、程序代碼更新等服務，但是沒有提出具體的實現方案，也不涉及到可靠的數據分發機制，在實際應用中需要做具體優化。文獻[3]提出了一種點對點的無線下載方式，是一種比較通用的無線下載方案。但是其方案數據校驗還是有點欠缺，沒有對整個Image進行校驗，可能會導致數據錯誤。

本文提出了一種基于通用架構、多點并發、可靠、高效、低能耗的無線下載解決方案。升級的傳感節點自主向協調器申請固件數據，自主發送數據申請包（POLL?Data Request），從而實現多節點并發升級，極大地提高了系統的效率及穩定性。

1? 結構劃分及算法選擇

1.1? 存儲結構劃分

在OTA升級模型中，需要把傳感節點及需要升級的設備內部程序存儲器在結構上分成三個區域：程序引導區、數據共享區和用戶裝載程序區。引導程序Bootloader主要實現固件程序的串口下載、固件數據的解壓縮、中斷向量的重映射及程序的跳轉；數據共享區存放引導程序與用戶程序的一些共享數據，例如固件的大小、版本等信息，用戶程序與引導程序都可以對該區域中數據進行操作；用戶裝載程序區用來存儲用戶應用程序，即實現用戶需求的應用程序。

1.2? 最大數據包及CRC選擇

在實際應用中，在無線升級過程中應該要盡量選擇最大包數據來發送，這樣可以減少整個固件發送的次數。而在未加密、短地址模式下，可用于傳輸的用戶數據只有99 B。本文支持的數據包最大值通過Zstack中的API函數afDataReqMTU（）來獲取。

因為要對整個數據包進行校驗，選用了CRC32，根據文獻[4]，CRC32最大能校驗的不沖突數據包長度為512 MB。

1.3? 數據壓縮

一個基于Zstack的傳感節點固件大小都是在100 KB以上，為了提高下載的速度，考慮對固件數據進行壓縮。為此，本文選用兩種無損壓縮算法進行評測：MiniLZO[5]與LZSS[6]，并在CC2530上做了移植，比較它們的性能。由于CC2530只有8 KB的ROM，考慮到對壓縮前后數據的存儲問題，所以在實際壓縮過程中需要將固件分割為3 KB大小的小塊進行分段壓縮。

本文選擇一個大小為123 072 B的固件，利用上述兩種壓縮算法對此固件進行性能比較。其中整體壓縮是該固件沒有進行分段壓縮之后的結果，具體測試結果如表1所示。

表1 LZSS與MiniLZO性能比較

[算法＼&；整體壓縮/壓縮比率＼&；分段壓縮/壓縮比率＼&；解壓程序

占ROM /B＼&；解壓時

間 /ms＼&；MiniLZO＼&；79 974 B/64.980%＼&；89 262 B/72.527%＼&；2 570＼&；1＼&；LZSS＼&；73 090 B/59.388%＼&；85 210 B/69.235%＼&；635＼&；11＼&；]

從表1中可以看出LZSS解壓程序比MiniLZO更節省ROM空間，但是LZSS解壓速度更慢，會導致傳感節點功耗與不穩定因素提高。所以本文提及的OTA方案壓縮解壓縮算法選用MiniLZO。

2? 系統實踐

OTA系統模型由無線升級主機（協調器）、傳感節點和路由設備組成，如圖1所示。升級主機和傳感節點中都集成SPI FLASH存儲器，用來存儲要升級的傳感器節點的固件。傳感節點采用SPI FALSH作為緩沖存儲介質，保證在下載的過程中不需要擦除應用程序，只有在SPI FLASH中的固件數據得到正確保證的情況下才被BootLoader程序拷貝到內部FLASH中，從而提高了系統的穩定性。

ZigBee標準[7]定義中，節點與其父節點通信采用POLL機制，節點通過周期性發送數據請求幀（POLL?Data Request）來查詢其父節點中有無數據要發送給它。這種機制一方面導致了節點功耗的增加，另一方面也給整個網絡帶來了一定的負荷，增加了系統不穩定因素。

<；E：＼LIHUI＼12月＼12.4＼現代電子技術201423＼Image＼07t1.tif>；

圖1 OTA系統模型

本系統在實際應用中關閉了周期性傳感節點的POLL功能，這導致傳感節點無法接收到協調器發給節點的數據。為此，本文重新構造自主數據請求（POLL?Data Request）機制，并設計了兩種特殊數據幀：配置數據申請幀和固件數據申請幀。

配置數據申請幀是在傳感節點與其父節點建立連接之后，傳感節點向協調器發送的一種數據幀。該數據幀包含節點當前運行的固件版本信息、IEEE地址等。在該數據幀發送之后，調用NLME_SetPollRate（）函數開啟POLL功能，同時也開啟等待協調器應答的超時定時器，開始等待協調器發送數據到該傳感節點；如果超時，定時器超時溢出。重復上述操作，具體流程如圖2（a）所示。

因為傳感節點采用自主數據請求的機制，所以在傳感節點與協調器關聯成功的時刻，要決定是否進行雙向通信，如圖2（b）所示。在傳感節點與協調器關聯成功后，傳感節點向協調器發送配置數據申請幀，協調器在收到該數據幀后就可以把相關的配置信息發送給它。傳感節點根據此數據包中的信息來決定是否要繼續與協調器保持數據通信或者固件升級。這種操作帶來了兩個方面的好處：一方面傳感節點不需要開啟周期POLL功能，可按需開啟該POLL功能，降低了網絡沖突的概率，提高了ZigBee網絡容量；另一方面降低了傳感節點的功耗，使傳感節點工作時間延長，提高了設備的可靠性。

如果傳感節點在規定時間內收到協調器的配置數據申請幀的應答幀，并把當前運行的固件版本與該應答幀數據中包含的固件信息做比較，如果節點當前運行固件版本比協調器中固件信息版本要低，則再根據協調器應答幀數據相關標志位，來決定是否需要進行升級工作，如圖2（b）所示。

傳感節點一旦進入升級模式，則開始周期發送固件數據申請幀數據，在發送完之后調用NLME_SetPollRate（）函數開啟POLL功能，打開超時等待定時器。固件數據申請幀中包含傳感節點要申請固件數據存儲于協調器SPI FLASH中的地址及固件數據的長度。協調器收到該固件數據申請幀之后，從該數據包中獲取傳感器節點申請固件按數據的存儲地址，并從SPI FLASH的該地址空間中讀取指定長度的數據，在收到傳感器Data?Requst包之后，把讀出的固件數據發送給該傳感節點。傳感器節點接收新的固件數據則寫入其SPI FLASH中，緊接著申請下一包數據。此流程一直循環到數據所有固件數據被申請完，具體流程如圖2（c）所示。

傳感節點申請完協調器中的新固件數據后，則把相應參數寫入到數據共享區，重啟進入Bootloader。引導程序根據共享區的數據信息，讀取傳感節點SPI FLASH中新固件數據并解壓到內部FLASH，從而實現傳感節點的固件升級。

3? 分析與評測

為了保證實驗數據的可靠性，本系統測試都是采取同一份傳感節點固件，大小為123 072 B。為了避免傳感節點因為網絡參數問題導致與協調器無法連接，在Zstack?2.5.1a協議棧[8]上做了修改，在傳感器節點多次發送失敗之后，則要重新初始化網絡參數，并重啟傳感器節點。本系統的驗證分三種方案進行，如表2所示。

表2 測試方案

[方案號碼＼&；固件數據申請

幀周期 /ms＼&；固件數據

是否壓縮＼&；同時升級

節點個數＼&；方案1＼&；100＼&；否＼&；2個、5個、10個＼&；方案2＼&；100＼&；是＼&；2個、5個、10個＼&；方案3＼&；50＼&；是＼&；2個、5個、10個＼&；]

方案1，方案2測試結果如圖3所示。方案2，方案3測試結果如圖4所示。

從圖3可以看出，固件數據的壓縮可以在一定程度上縮短傳感節點固件升級的時間，進而提升了OTA性能。隨著同時申請升級的節點數目的增多，節點升級的時間相對于同時申請下載節點較少的情況下完成升級所花費的時間會有所增加，因為節點增多導致無線沖突的概率增大，而數據的重發機制導致傳感節點升級的花費時間增加。同時，升級節點的增多，也會導致有些傳感節點因為多次重發不成功，而引起傳感器節點重置網絡參數，重啟并重新開始升級工作，如圖4（c）中序號為6、7、9、10號的節點。

從圖4可以看出，縮短傳感節點固件申請包的時間間隔，在傳感節點比較少的情況下，極大地縮短了升級所花費的時間。但是隨著傳感節點同時申請升級的個數增加，無線沖突的概率也隨之增大，導致節點重啟并重新升級的節點個數也隨之增多，如圖4（c）所示。

從圖3與圖4可以看出，隨著同時申請升級的傳感節點個數的增加，傳感節點斷網重啟重連的概率也會隨之增加；縮短固件數據申請幀的周期，在傳感節點比較少的狀況下極大地提高了OTA的性能。根據上述測試結果，確定一個協調器在同一時刻只允許5個傳感節點同時升級的方案，且每個節點申請的時間間隔為100 ms。

4? 總結與展望

本論文提出了一種基于ZigBee網絡OTA技術的改進方案，設計的方案具有多并發、高可靠、低功耗及通用性強的特點。文中對代碼數據進行壓縮處理，在代碼量在很大的情況下，既可以實現傳輸數據量的減少，增加系統的穩定性和可靠性，又降低了硬件成本。對于數據的安全性，本文中沒有涉及，目前系統沒有采用特定加密算法，所以無線下載的安全性等方面有進一步的討論空間。

參考文獻

[1] ZigBee Alliance. ZigBee over?the?air upgrading cluster [EB/OL]. [2012?05?28]. http：//www.zigbee.org/en/spec_download/download_request.

[2] 尹令，周皓恩，劉才興，等.無線傳感器網絡空中下載協議的研究[J].湘潭大學自然科學學報，2010，32（2）：112?117.

[3] 生鳳中，荊雷，李建業.基于 CC1110 單片機的無線升級方法研究[J].電子技術應用，2012，38（11）：139?142.

[4] FARAHANI S. ZigBee wireless networks and transceivers [M]. UK： Newnes， 2011.

[5] OBERHUMER M. Mini version of the LZO real?time data compression library [J/OL]. [2012?08?13]. github.com/markus?ober.

[6] BERLIN G J. Method for compression of data using single pass LZSS and run?length encoding： US， 5，701，125 [P]. 1997?12?23.

[7] Zigbee Alliance. Zigbee specification [M/OL]. [2013?04?22]. http：//www.zb4osgi.aaloa.org/redmine/attachments/download/46/1053474r17zb tsc?zigbee?specification.

[8] Texas Instruments. Z?stack developer′s guide [EB/OL]. [2012?02?08]. http：//www. ti. com. cn/cn/lit/an/swra176/swra176.