基于ZigBee協(xié)議OTA技術(shù)的改進方法研究

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

現(xiàn)代電子技術(shù) 2014年23期

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

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

關(guān)鍵詞： ZigBee； OTA；數(shù)據(jù)壓縮； 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根據(jù)ZigBee的相關(guān)OTA標準[1]標準編寫了相應(yīng)實現(xiàn)代碼，但是對功耗方面關(guān)注度比較少，而且必須要配合TI的軟件才能實現(xiàn)升級。國內(nèi)針對OTA技術(shù)已有相關(guān)研究，文獻[2]涉及無線傳感網(wǎng)絡(luò)空中下載協(xié)議，該協(xié)議是一種具有數(shù)據(jù)傳輸、節(jié)點狀態(tài)控制功能的應(yīng)用層協(xié)議，為無線傳感器網(wǎng)絡(luò)提供無線傳感器節(jié)點狀態(tài)控制、程序代碼更新等服務(wù)，但是沒有提出具體的實現(xiàn)方案，也不涉及到可靠的數(shù)據(jù)分發(fā)機制，在實際應(yīng)用中需要做具體優(yōu)化。文獻[3]提出了一種點對點的無線下載方式，是一種比較通用的無線下載方案。但是其方案數(shù)據(jù)校驗還是有點欠缺，沒有對整個Image進行校驗，可能會導(dǎo)致數(shù)據(jù)錯誤。

本文提出了一種基于通用架構(gòu)、多點并發(fā)、可靠、高效、低能耗的無線下載解決方案。升級的傳感節(jié)點自主向協(xié)調(diào)器申請固件數(shù)據(jù)，自主發(fā)送數(shù)據(jù)申請包（POLL?Data Request），從而實現(xiàn)多節(jié)點并發(fā)升級，極大地提高了系統(tǒng)的效率及穩(wěn)定性。

1? 結(jié)構(gòu)劃分及算法選擇

1.1? 存儲結(jié)構(gòu)劃分

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

1.2? 最大數(shù)據(jù)包及CRC選擇

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

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

1.3? 數(shù)據(jù)壓縮

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

本文選擇一個大小為123 072 B的固件，利用上述兩種壓縮算法對此固件進行性能比較。其中整體壓縮是該固件沒有進行分段壓縮之后的結(jié)果，具體測試結(jié)果如表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更節(jié)省ROM空間，但是LZSS解壓速度更慢，會導(dǎo)致傳感節(jié)點功耗與不穩(wěn)定因素提高。所以本文提及的OTA方案壓縮解壓縮算法選用MiniLZO。

2? 系統(tǒng)實踐

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

ZigBee標準[7]定義中，節(jié)點與其父節(jié)點通信采用POLL機制，節(jié)點通過周期性發(fā)送數(shù)據(jù)請求幀（POLL?Data Request）來查詢其父節(jié)點中有無數(shù)據(jù)要發(fā)送給它。這種機制一方面導(dǎo)致了節(jié)點功耗的增加，另一方面也給整個網(wǎng)絡(luò)帶來了一定的負荷，增加了系統(tǒng)不穩(wěn)定因素。

<；E：＼LIHUI＼12月＼12.4＼現(xiàn)代電子技術(shù)201423＼Image＼07t1.tif>；

圖1 OTA系統(tǒng)模型

本系統(tǒng)在實際應(yīng)用中關(guān)閉了周期性傳感節(jié)點的POLL功能，這導(dǎo)致傳感節(jié)點無法接收到協(xié)調(diào)器發(fā)給節(jié)點的數(shù)據(jù)。為此，本文重新構(gòu)造自主數(shù)據(jù)請求（POLL?Data Request）機制，并設(shè)計了兩種特殊數(shù)據(jù)幀：配置數(shù)據(jù)申請幀和固件數(shù)據(jù)申請幀。

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

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

如果傳感節(jié)點在規(guī)定時間內(nèi)收到協(xié)調(diào)器的配置數(shù)據(jù)申請幀的應(yīng)答幀，并把當(dāng)前運行的固件版本與該應(yīng)答幀數(shù)據(jù)中包含的固件信息做比較，如果節(jié)點當(dāng)前運行固件版本比協(xié)調(diào)器中固件信息版本要低，則再根據(jù)協(xié)調(diào)器應(yīng)答幀數(shù)據(jù)相關(guān)標志位，來決定是否需要進行升級工作，如圖2（b）所示。

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

傳感節(jié)點申請完協(xié)調(diào)器中的新固件數(shù)據(jù)后，則把相應(yīng)參數(shù)寫入到數(shù)據(jù)共享區(qū)，重啟進入Bootloader。引導(dǎo)程序根據(jù)共享區(qū)的數(shù)據(jù)信息，讀取傳感節(jié)點SPI FLASH中新固件數(shù)據(jù)并解壓到內(nèi)部FLASH，從而實現(xiàn)傳感節(jié)點的固件升級。

3? 分析與評測

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

表2 測試方案

[方案號碼＼&；固件數(shù)據(jù)申請

幀周期 /ms＼&；固件數(shù)據(jù)

是否壓縮＼&；同時升級

節(jié)點個數(shù)＼&；方案1＼&；100＼&；否＼&；2個、5個、10個＼&；方案2＼&；100＼&；是＼&；2個、5個、10個＼&；方案3＼&；50＼&；是＼&；2個、5個、10個＼&；]

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

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

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

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

4? 總結(jié)與展望

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

參考文獻

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

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

[3] 生鳳中，荊雷，李建業(yè).基于 CC1110 單片機的無線升級方法研究[J].電子技術(shù)應(yīng)用，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.