?
無(wú)線(xiàn)傳感網(wǎng)絡(luò)是由大量體積小,供電資源有限,并配置一定計(jì)算能力和無(wú)線(xiàn)通訊能力的傳感節(jié)點(diǎn)組成。對(duì)于傳感網(wǎng)絡(luò)系統(tǒng),一定存在程序代碼更新和維護(hù)的需求,但由于傳感節(jié)點(diǎn)分散部署的特點(diǎn),使得網(wǎng)絡(luò)遠(yuǎn)程節(jié)點(diǎn)的程序升級(jí)變得異常困難。為此,空中下載(over the air, OTA)提供了一種有效的更新手段。本文首先介紹基于 ZigBee協(xié)議的OTA系統(tǒng),并在CC2530F256 硬件平臺(tái)作出驗(yàn)證。最后,在Z-Stack協(xié)議棧中,設(shè)計(jì)出一種鏡像頁(yè)請(qǐng)求的OTA更新方式,并通過(guò)實(shí)驗(yàn)測(cè)試,與原有的鏡像塊請(qǐng)求方式進(jìn)行了比較分析。實(shí)驗(yàn)結(jié)果表明,鏡像頁(yè)請(qǐng)求方式可以大大減少網(wǎng)絡(luò)的更新流量,從而提高節(jié)點(diǎn)的更新效率。
引言
近年來(lái),由于硬件成本的下降以及制造工藝的進(jìn)步,無(wú)線(xiàn)傳感網(wǎng)絡(luò)技術(shù)逐步取得大規(guī)模商業(yè)應(yīng)用,如醫(yī)療監(jiān)控,智能電網(wǎng)和智能家居[1]。對(duì)于任何一個(gè)嵌入式計(jì)算機(jī)系統(tǒng),都存在程序代碼升級(jí)的需要。在無(wú)線(xiàn)傳感網(wǎng)絡(luò)的應(yīng)用環(huán)境中,由于大量節(jié)點(diǎn)分散性部署,節(jié)點(diǎn)的回收工作變得異常困難,使傳統(tǒng)的物理連接的程序更新手段不再適用。對(duì)此,一種有效的解決方案是OTA技術(shù)。
空中下載技術(shù)起源于移動(dòng)電話(huà)網(wǎng)絡(luò),能夠通過(guò)移動(dòng)通信網(wǎng)絡(luò)(如GSM)對(duì)SIM卡數(shù)據(jù)進(jìn)行遠(yuǎn)程管理與更新[2]。借鑒于移動(dòng)通信網(wǎng)絡(luò),空中下載技術(shù)也能應(yīng)用于無(wú)線(xiàn)傳感網(wǎng)絡(luò)。與網(wǎng)絡(luò)層的路由協(xié)議[3]不同,代碼分發(fā)協(xié)議[4]是支撐OTA的核心技術(shù)。前者關(guān)注的是如何迅速高效地中轉(zhuǎn)網(wǎng)絡(luò)中的數(shù)據(jù)信息,后者關(guān)注的是如何向各節(jié)點(diǎn)完整無(wú)誤地傳遞更新代碼[5]。目前,成熟的代碼分發(fā)協(xié)議已經(jīng)提出,典型的如基于TinyOS系統(tǒng)的Xnp[6]與Deluge[7],前者提出了單跳網(wǎng)絡(luò)的更新方案,后者支持多跳網(wǎng)絡(luò)更新功能,但都需要具體的硬件平臺(tái)支持。
本文移植并驗(yàn)證了一種基于ZigBee協(xié)議[8]的空中下載技術(shù),其分發(fā)協(xié)議支持點(diǎn)對(duì)多傳輸更新功能,多跳網(wǎng)絡(luò)的代碼分發(fā)功能由路由協(xié)議支撐。在Z-Stack協(xié)議棧[9]下,僅僅支持鏡像塊請(qǐng)求功能,更新效率并不理想。針對(duì)此問(wèn)題,設(shè)計(jì)出一種高效的鏡像頁(yè)請(qǐng)求功能,能夠提高點(diǎn)對(duì)多的傳輸更新效率,并減少網(wǎng)絡(luò)流量。
1. OTA概述
ZigBee協(xié)議規(guī)范使用了IEEE 802.15.4定義的物理層(PHY)和媒體介質(zhì)訪(fǎng)問(wèn)層(MAC),并在此基礎(chǔ)上定義了網(wǎng)絡(luò)層(NWK)應(yīng)用層(APL)。針對(duì)無(wú)線(xiàn)傳感網(wǎng)絡(luò)重編程技術(shù)的需求,ZigBee聯(lián)盟在原有協(xié)議的框架上,提出了一種OTA規(guī)范[10],作為一個(gè)系統(tǒng)可選的功能模塊。
圖1為OTA系統(tǒng)的結(jié)構(gòu)示意圖,整個(gè)系統(tǒng)主要由3部分構(gòu)成:OTA應(yīng)用控制臺(tái),OTA服務(wù)器,OTA客戶(hù)端。其中OTA應(yīng)用控制臺(tái)是上位機(jī)管理軟件,負(fù)責(zé)OTA鏡像管理,網(wǎng)絡(luò)節(jié)點(diǎn)信息陳列與發(fā)送更新命令;OTA服務(wù)器負(fù)責(zé)向遠(yuǎn)程節(jié)點(diǎn)無(wú)線(xiàn)發(fā)送升級(jí)鏡像,并通過(guò)串口與上位機(jī)連接,向應(yīng)用控制臺(tái)匯報(bào)各節(jié)點(diǎn)更新進(jìn)度信息等;OTA客戶(hù)端是指遠(yuǎn)程網(wǎng)絡(luò)中的待升級(jí)節(jié)點(diǎn)。
根據(jù)代碼的更新范圍,分為整體代碼更新與基于差異性的更新[11]。前者是把所有可執(zhí)行的二進(jìn)制代碼打包成一個(gè)鏡像分發(fā)給節(jié)點(diǎn),后者是通過(guò)比較新舊鏡像文件之間的差異,產(chǎn)生一個(gè)編輯腳本,然后把這個(gè)腳本分發(fā)到網(wǎng)絡(luò)中的節(jié)點(diǎn)進(jìn)行差異性更新。毫無(wú)疑問(wèn),前者需要傳輸?shù)臄?shù)據(jù)量較大,一般為上千字節(jié)級(jí),增加了網(wǎng)絡(luò)負(fù)擔(dān),但代碼更新操作相對(duì)簡(jiǎn)單;后者發(fā)送的數(shù)據(jù)量雖少,但增加了更新過(guò)程的復(fù)雜度,對(duì)處理器產(chǎn)生更大的負(fù)擔(dān),帶來(lái)較大的能源損耗。由于ZigBee協(xié)議對(duì)網(wǎng)絡(luò)節(jié)點(diǎn)的低功耗標(biāo)準(zhǔn)有嚴(yán)格的要求,其OTA代碼分發(fā)協(xié)議采用前者的鏡像傳輸方式。
服務(wù)器與客戶(hù)端之間的數(shù)據(jù)交互過(guò)程如圖2所示。首先OTA服務(wù)器通過(guò)單播或者廣播方式向OTA客戶(hù)端(節(jié)點(diǎn))發(fā)送鏡像公告(Image Notify),指示新鏡像已經(jīng)準(zhǔn)備好。收到鏡像提示信息后,節(jié)點(diǎn)就向OTA服務(wù)器發(fā)送查詢(xún)下一個(gè)鏡像請(qǐng)求(Query Next Image Request),此請(qǐng)求信息包含了當(dāng)前運(yùn)行固件的版本信息。收到該請(qǐng)求后,OTA服務(wù)器作出響應(yīng)(Query Next Image Response)。隨后,OTA客戶(hù)端與OTA服務(wù)器通過(guò)二次握手機(jī)制,鏡像塊請(qǐng)求(Image Block Request)和鏡像塊響應(yīng)(Image Block Response),完成整個(gè)鏡像傳輸過(guò)程。當(dāng)OTA客戶(hù)端收到鏡像塊數(shù)據(jù)后,把塊數(shù)據(jù)寫(xiě)到第二存儲(chǔ)區(qū)(客戶(hù)端當(dāng)前運(yùn)行的鏡像保存在第一存儲(chǔ)區(qū))。完成下載后,節(jié)點(diǎn)將對(duì)下載后的鏡像進(jìn)行CRC校驗(yàn)。最后,當(dāng)節(jié)點(diǎn)需要更新時(shí),把新鏡像從第二存儲(chǔ)區(qū)復(fù)制到第一存儲(chǔ)區(qū),新固件開(kāi)始運(yùn)行,從而完成了整個(gè)升級(jí)過(guò)程。
2. OTA系統(tǒng)設(shè)計(jì)
本文的OTA系統(tǒng)基于TI公司的ZigBee SOC芯片CC2530F256[12]設(shè)計(jì),包括硬件與軟件的設(shè)計(jì)。其中硬件部分主要涉及CC2530 F256內(nèi)部Flash存儲(chǔ)空間分配方式與鏡像存儲(chǔ)方式的選擇;軟件部分介紹了OTA啟動(dòng)代碼工作流程。
2. 1硬件系統(tǒng)
CC2530F256內(nèi)部集成一個(gè)增強(qiáng)型8051單片機(jī),擁有8KB SRAM和256KB內(nèi)部flash存儲(chǔ)器。內(nèi)部flash主要用來(lái)保存程序代碼和常量數(shù)據(jù)。由于傳統(tǒng)8051 代碼存儲(chǔ)空間尋址范圍只有64KB,CC2530把內(nèi)部256KB flash分成8個(gè)bank,每一個(gè)bank大小是32KB,通過(guò)寄存器FMAP.MAP[2:0]選擇不同的bank映射到代碼存儲(chǔ)空間,解決了尋址空間受限的問(wèn)題。
對(duì)于OTA客戶(hù)端,啟動(dòng)代碼位于bank0的0x0000到0x0800地址區(qū)域,大小為2KB。其余的254KB的flash空間,用來(lái)存儲(chǔ)當(dāng)前固件和其他信息。值得注意的是,0x0888~0x088B區(qū)域存放了CRC校驗(yàn)信息,0x088C~0x0897區(qū)域存放了PREAMBLE,即鏡像大小,制造商ID,鏡像類(lèi)型和鏡像版本號(hào)信息。另外,bank7最后的14KB空間(0x7C800~0x7FFFF)用作非易失性(None volatile, NV)變量區(qū)(12KB)和特定信息保留區(qū)(2KB)。
OTA系統(tǒng)升級(jí)方案有兩種,分別是片內(nèi)flash升級(jí)和片外flash升級(jí)。片內(nèi)flash的方案是把256KB的flash大小分成兩半,前一半(第一存儲(chǔ)區(qū))提供給當(dāng)前運(yùn)行鏡像存儲(chǔ),后一半(第二存儲(chǔ)區(qū))提供給新鏡像存儲(chǔ);片外flash的方案是把片內(nèi)flash作為第一存儲(chǔ)區(qū),外擴(kuò)的flash作為第二存儲(chǔ)區(qū)。考慮到一般程序固件大小都超過(guò)128KB,和以后程序功能升級(jí)的擴(kuò)展性,本文采用片外flash的方案。采用的片外flash(M25PE20)容量為256KB,通過(guò)SPI總線(xiàn)與CC2530之間傳輸數(shù)據(jù)。
2. 2軟件系統(tǒng)
對(duì)于基于任務(wù)事件輪詢(xún)機(jī)制的Z-Stack工程,默認(rèn)是沒(méi)有添加OTA功能。如果節(jié)點(diǎn)需要開(kāi)啟OTA功能,首先需要燒寫(xiě)OTA的啟動(dòng)代碼。當(dāng)節(jié)點(diǎn)完成鏡像接收之后,對(duì)新鏡像進(jìn)行CRC校驗(yàn),并清空當(dāng)前鏡像的CRC信息,然后重啟。當(dāng)節(jié)點(diǎn)重啟后,首先跳轉(zhuǎn)到啟動(dòng)代
碼的地址,開(kāi)始執(zhí)行如圖3所示的工作流程。由于內(nèi)部鏡像的CRC信息被清空,所以被判斷為不正確而執(zhí)行下一步。由于為0的CRC信息標(biāo)志著不需要被重新校驗(yàn),故執(zhí)行將新鏡像復(fù)制到片內(nèi)Flash的操作,并產(chǎn)生新鏡像的CRC信息。然后,重新執(zhí)行啟動(dòng)代碼。新鏡像啟動(dòng)時(shí)讀取其CRC信息,再次判斷后跳轉(zhuǎn)到應(yīng)用程序區(qū),完成整個(gè)啟動(dòng)過(guò)程。
3. OTA的鏡像頁(yè)請(qǐng)求實(shí)現(xiàn)
根據(jù)ZigBee OTA的規(guī)范,OTA客戶(hù)端向OTA服務(wù)器請(qǐng)求鏡像的方式有兩種,分別是鏡像塊請(qǐng)求與鏡像頁(yè)請(qǐng)求。前者是基于二次握手機(jī)制,鏡像塊請(qǐng)求包含了已下載鏡像的偏移量(File offset)與每次傳輸?shù)溺R像塊大小等信息。當(dāng)OTA服務(wù)器接收到該請(qǐng)求后,根據(jù)請(qǐng)求節(jié)點(diǎn)的短地址,鏡像偏移量和鏡像塊大小等信息,通過(guò)串口向OTA應(yīng)用控制臺(tái)索取特定的鏡像塊。隨后,OTA服務(wù)器回復(fù)的鏡像塊響應(yīng)包含了該鏡像塊數(shù)據(jù)。當(dāng)節(jié)點(diǎn)收到鏡像塊數(shù)據(jù)后,把塊數(shù)據(jù)寫(xiě)到第二存儲(chǔ)區(qū),隨即更新下載鏡像的偏移量,并準(zhǔn)備下一輪的請(qǐng)求。
鏡像塊請(qǐng)求的優(yōu)點(diǎn)是能夠通過(guò)二次握手機(jī)制,確保每次傳輸?shù)溺R像塊數(shù)據(jù)準(zhǔn)確無(wú)誤。但是大量的請(qǐng)求信息,無(wú)疑給整個(gè)網(wǎng)絡(luò)的流量造成了嚴(yán)重的負(fù)擔(dān)。再者,節(jié)點(diǎn)不停地發(fā)送請(qǐng)求命令,也加劇了自身的能源損耗。在外界干擾并不嚴(yán)重或點(diǎn)對(duì)點(diǎn)傳輸?shù)膽?yīng)用場(chǎng)合,節(jié)點(diǎn)與服務(wù)器交換數(shù)據(jù)的過(guò)程并不會(huì)出現(xiàn)大量的丟包現(xiàn)象,基于塊請(qǐng)求的OTA更新方式效率較低。于是需要設(shè)計(jì)出一種能夠減輕網(wǎng)絡(luò)流量,提高效率的更新手段。
鏡像塊請(qǐng)求功能在大部分的ZigBee開(kāi)發(fā)平臺(tái)上(如TI的Z-Stack協(xié)議棧)已得到實(shí)現(xiàn),但并沒(méi)有提供鏡像頁(yè)請(qǐng)求功能。本文根據(jù)ZigBee OTA的規(guī)范,在Z-Stack協(xié)議棧上設(shè)計(jì)出鏡像頁(yè)請(qǐng)求的更新方式。頁(yè)請(qǐng)求命令與塊請(qǐng)求命令類(lèi)似,在數(shù)據(jù)幀當(dāng)中附加了鏡像頁(yè)大小(Page Size)與響應(yīng)間隔(Response Spacing)信息。當(dāng)OTA服務(wù)器收到一次頁(yè)請(qǐng)求后,在一定時(shí)間間隔內(nèi),多次向節(jié)點(diǎn)發(fā)送塊響應(yīng),免去了多次塊請(qǐng)求。其中塊響應(yīng)的次數(shù)由鏡像頁(yè)大小決定,時(shí)間間隔由響應(yīng)間隔設(shè)定。正因?yàn)檎?qǐng)求命令的銳減,能夠大大減輕整個(gè)網(wǎng)絡(luò)流量的負(fù)擔(dān),并提高節(jié)點(diǎn)的傳輸更新效率。
Z-Stack運(yùn)行在一個(gè)OSAL操作系統(tǒng)上,OSAL是一種基于任務(wù)事件調(diào)度機(jī)制的操作系統(tǒng)。每個(gè)任務(wù)包含若干事件,每個(gè)事件對(duì)應(yīng)一個(gè)事件號(hào)。當(dāng)一個(gè)事件需要產(chǎn)生時(shí),可以通過(guò)API函數(shù)設(shè)置相應(yīng)的事件號(hào),然后提交給操作系統(tǒng)調(diào)度觸發(fā)。本文設(shè)計(jì)的鏡像頁(yè)請(qǐng)求功能正是基于這種機(jī)制。如圖4所示,OTA服務(wù)器為每一個(gè)請(qǐng)求更新的節(jié)點(diǎn)分配一個(gè)事件號(hào),并通過(guò)請(qǐng)求節(jié)點(diǎn)的短地址索引,設(shè)置特定的事件。進(jìn)入事件后,OTA服務(wù)器通過(guò)串口向OTA應(yīng)用控制臺(tái)請(qǐng)求鏡像數(shù)據(jù)塊,并向節(jié)點(diǎn)發(fā)送鏡像塊數(shù)據(jù)。通過(guò)把事件添加到定時(shí)器鏈表,就能夠以響應(yīng)間隔為時(shí)間單位,循環(huán)發(fā)送鏡像塊數(shù)據(jù),直到累計(jì)的發(fā)送鏡像塊大小等于節(jié)點(diǎn)的請(qǐng)求鏡像頁(yè)大小,從而完成一次鏡像頁(yè)請(qǐng)求的傳輸過(guò)程。
Z-Stack協(xié)議棧有一個(gè)MAC定時(shí)器為操作系統(tǒng)提供計(jì)時(shí)。該定時(shí)器以每1ms為單位,更新系統(tǒng)的定時(shí)器事件鏈表。定時(shí)器事件鏈表如圖5所示,鏈表的每一個(gè)結(jié)點(diǎn)記錄了任務(wù)號(hào)(task_id),事件號(hào)(event_flag)與計(jì)時(shí)時(shí)間( timeout )和下一個(gè)結(jié)點(diǎn)地址(*next)。圖中ZCL_OTA_MT_READn定義為每個(gè)請(qǐng)求節(jié)點(diǎn)對(duì)應(yīng)的事件號(hào),Response Spacing即為節(jié)點(diǎn)請(qǐng)求的響應(yīng)間隔,把兩者添加到鏈表當(dāng)中。當(dāng)計(jì)時(shí)時(shí)間減為0后,系統(tǒng)自動(dòng)設(shè)定對(duì)應(yīng)的事件號(hào),從而使OTA服務(wù)器循環(huán)地向OTA應(yīng)用控制臺(tái)索取鏡像塊數(shù)據(jù),并向節(jié)點(diǎn)發(fā)送鏡像塊響應(yīng)。
以下是OTA服務(wù)器處理鏡像頁(yè)請(qǐng)求的部分代碼段:
typedef struct
{
uint32 SeverfileOffset; //OTA服務(wù)器讀取鏡像的偏移量,與OTA客戶(hù)端的同步
afAddrType_t Psourceaddress; //OTA客戶(hù)端短地址
zclOTA_FileID_t FileID; //鏡像信息,包括鏡像類(lèi)型,制造商ID與版本號(hào)
uint16 ResponseTime; //響應(yīng)間隔時(shí)間
uint8 Length; //鏡像塊大小
uint8 Count; //鏡像頁(yè)計(jì)數(shù)
} zclOTA_Address_Index; //鏡像頁(yè)請(qǐng)求屬性結(jié)構(gòu)體
zclOTA_Address_Index Address_index[]; //鏡像頁(yè)請(qǐng)求屬性結(jié)構(gòu)體數(shù)組
if ( events & ZCL_OTA_MT_READn ) //處理OTA客戶(hù)端鏡像頁(yè)請(qǐng)求事件
{
ZStatus_t status = ZFailure; //初始化狀態(tài)值
Address_index[n].Count--; //自減鏡像頁(yè)計(jì)數(shù)變量
if(Address_index[n].SeverfileOffset 》= Imagesize) //判斷鏡像偏移量是否超出鏡像大小
{
return ( events ^ ZCL_OTA_MT_READn ); //如果超出直接退出事件處理
}
//OTA服務(wù)器根據(jù)OTA客戶(hù)端的鏡像頁(yè)請(qǐng)求信息,向應(yīng)用控制臺(tái)索取鏡像塊數(shù)據(jù)
Status = MT_OtaFileReadReq(&(Address_index[n].Psourceaddress), &(Address_index[n].FileID), Address_index[n].Length, Address_index[n].SeverfileOffset);
if (status == ZSuccess) //假如索取成功,累加已請(qǐng)求的鏡像偏移量
{
Address_index[n].SeverfileOffset += Address_index[n].Length;
}
if(Address_index[n].Count 》 0) //判斷累計(jì)的請(qǐng)求鏡像塊大小是否超出鏡像頁(yè)大小
{
//假如沒(méi)超出,把該鏡像頁(yè)處理時(shí)間繼續(xù)添加到定時(shí)器鏈表,等待下一輪的處理
osal_start_timerEx(zclOTA_TaskID, ZCL_OTA_MT_READn,Address_index[n].ResponseTime);
}
//結(jié)束處理事件,并清除該事件號(hào)
return ( events ^ ZCL_OTA_MT_READn );
}
4. 驗(yàn)證與分析
4. 1功能驗(yàn)證
為了驗(yàn)證OTA功能,在CC2530F256平臺(tái)上搭建一個(gè)小型樹(shù)狀網(wǎng)絡(luò),并使用Packet Sniffer[13]對(duì)OTA更新時(shí)的節(jié)點(diǎn)進(jìn)行抓包分析。如圖6(a)所示,四個(gè)傳感節(jié)點(diǎn)的當(dāng)前固件并沒(méi)有添加溫度采集功能,所以溫度顯示為0;在新的固件中添加了溫度采集函數(shù),用于驗(yàn)證OTA更新成功。
對(duì)于某些特定應(yīng)用,需要節(jié)點(diǎn)更新固件后能夠保持原來(lái)的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)。內(nèi)部Flash的NV區(qū)能夠保存節(jié)點(diǎn)的網(wǎng)絡(luò)信息,只要在工程添加NV_INIT與NV_RESTORE預(yù)編譯項(xiàng),節(jié)點(diǎn)在掉電后還能恢復(fù)原來(lái)網(wǎng)絡(luò)信息。
對(duì)四個(gè)傳感節(jié)點(diǎn)進(jìn)行OTA更新。如圖6(b)所示,OTA更新后,溫度采集功能成功添加,而且傳感節(jié)點(diǎn)的網(wǎng)絡(luò)短地址沒(méi)有發(fā)生變化,網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)保持完整,驗(yàn)證了進(jìn)行OTA鏡像升級(jí)過(guò)程中,并不會(huì)對(duì)NV區(qū)進(jìn)行擦除,有利于節(jié)點(diǎn)網(wǎng)絡(luò)信息的恢復(fù)。
在OTA更新過(guò)程中,應(yīng)用層的數(shù)據(jù)幀格式如圖7所示。OTA服務(wù)器被配置為路由器(0x06BC),對(duì)傳感節(jié)點(diǎn)(0x0002)進(jìn)行點(diǎn)對(duì)點(diǎn)更新。第一條短幀是子路由向OTA服務(wù)器發(fā)送Image Block Request,應(yīng)用層載荷從第4字節(jié)開(kāi)始記錄了新鏡像的制造商ID(0x5678),鏡像類(lèi)型(0x1234),版本號(hào)(0x00000002)和鏡像塊偏移量。最后1個(gè)字節(jié)記錄了每次傳送最大鏡像塊大小(OTA_MAX_MTU),默認(rèn)為0x20,即為32字節(jié)。第二條長(zhǎng)幀是OTA服務(wù)器發(fā)送的Image Block Response,載荷記錄格式與前者類(lèi)似,并在最大鏡像塊大小字節(jié)后面附上32字節(jié)鏡像塊信息,從而完成一個(gè)鏡像塊傳輸周期。
4. 2效率分析
搭建一個(gè)星形網(wǎng)絡(luò),把OTA服務(wù)器配置成協(xié)調(diào)器,把所有OTA客戶(hù)端配置成節(jié)點(diǎn),并進(jìn)行如下兩個(gè)實(shí)驗(yàn)。
實(shí)驗(yàn)一(測(cè)試數(shù)據(jù)如表1、表2所示):為了對(duì)比分析兩種更新手段的效率,分別使用鏡像塊請(qǐng)求命令與鏡像頁(yè)請(qǐng)求命令,對(duì)節(jié)點(diǎn)進(jìn)行OTA更新。星形網(wǎng)絡(luò)中,通過(guò)廣播Image Notify,能夠?qū)Χ喙?jié)點(diǎn)進(jìn)行批量更新。網(wǎng)絡(luò)規(guī)模分別為1個(gè)節(jié)點(diǎn)到6個(gè)節(jié)點(diǎn),測(cè)量了不同規(guī)模網(wǎng)絡(luò)下節(jié)點(diǎn)完成更新傳輸所需的時(shí)間。Min與Max分別指最快與最慢完成更新傳輸?shù)墓?jié)點(diǎn)對(duì)應(yīng)的時(shí)間,Ave指平均每個(gè)節(jié)點(diǎn)完成更新傳輸所需時(shí)間(使用Max值計(jì)算)。其中鏡像頁(yè)請(qǐng)求設(shè)置的Response Spacing為100ms,Page size為640字節(jié)。鏡像大小統(tǒng)一為113K字節(jié),并修改OTA_MAX_MTU大小為64字節(jié)。節(jié)點(diǎn)與OTA服務(wù)器間隔均為5米。
表1 鏡像塊請(qǐng)求的傳輸時(shí)間(響應(yīng)間隔= 100ms)
網(wǎng)絡(luò)節(jié)點(diǎn)數(shù)123456
Min. Time/s207.2209.3214.4217.5221.4230.0
Max. Time/s207.2209.3214.4217.5222.9231.7
Ave. Time/s207.2104.771.554.444.638.6
表2 鏡像頁(yè)請(qǐng)求的傳輸時(shí)間(響應(yīng)間隔= 100ms)
網(wǎng)絡(luò)節(jié)點(diǎn)數(shù)123456
Min. Time/s179.6108.1180.6181.3182.6184.0
Max. Time/s179.6180.1180.6181.3184.7193.0
Ave. Time/s179.690.160.245.336.932.7
實(shí)驗(yàn)二(測(cè)試數(shù)據(jù)如表3所示):為了測(cè)試鏡像頁(yè)請(qǐng)求在點(diǎn)對(duì)點(diǎn)更新情況下的最高效率,設(shè)定最短的Response Spacing為10ms,分別測(cè)量不同Page Size下的單個(gè)節(jié)點(diǎn)更新傳輸時(shí)間。使用CC2531(支持USB)作為OTA服務(wù)器,能夠縮短服務(wù)器向應(yīng)用控制臺(tái)索取鏡像塊數(shù)據(jù)的時(shí)間,進(jìn)一步加快更新傳輸效率。鏡像大小統(tǒng)一為113K字節(jié),OTA_MAX_MTU大小為64字節(jié),節(jié)點(diǎn)與OTA服務(wù)器間隔均為5米。
表3 不同鏡像頁(yè)大小下的傳輸時(shí)間(Response Spacing = 10ms)
Page Size/byte64
(1)128
(1/2)192
(1/3)256
(1/4)320
(1/5)640
(1/10)1024
(1/16)3200
(1/50)6400
(1/100)
Time/s77.253.746.243.436.431.529.928.327.3
實(shí)驗(yàn)一中,使用鏡像塊請(qǐng)求,節(jié)點(diǎn)發(fā)送鏡像塊請(qǐng)求所需時(shí)間為15.5ms,OTA服務(wù)器返回鏡像塊響應(yīng)所需時(shí)間實(shí)際為96ms左右,來(lái)回確認(rèn)幀時(shí)間大概為1.92+3.84=5.76ms。一個(gè)更新周期傳輸鏡像塊大小為64字節(jié),完成113K字節(jié)大小的鏡像傳送需要1765個(gè)周期。總時(shí)間為(96+15.5+5.76)*1765=206963ms,這與表1測(cè)量值207.2基本符合。本文設(shè)計(jì)的鏡像頁(yè)請(qǐng)求,鏡像頁(yè)大小為640字節(jié),每次傳輸鏡像塊大小為64字節(jié),即節(jié)點(diǎn)發(fā)送1次頁(yè)請(qǐng)求可以得到10次塊響應(yīng)。當(dāng)更新1個(gè)節(jié)點(diǎn)時(shí),使用鏡像頁(yè)請(qǐng)求可以把原來(lái)的1765條請(qǐng)求命令和1765條確認(rèn)幀減少十分之九,共減少3177條傳輸幀。減少的傳輸幀數(shù)量隨著節(jié)點(diǎn)數(shù)目成比例增長(zhǎng)。對(duì)比表1與表2,可以發(fā)現(xiàn)無(wú)論節(jié)點(diǎn)數(shù)目為多少,頁(yè)請(qǐng)求的平均每個(gè)節(jié)點(diǎn)的更新傳輸時(shí)間都比塊請(qǐng)求的要短。其中發(fā)送鏡像頁(yè)請(qǐng)求時(shí)間為15.5ms,請(qǐng)求確認(rèn)幀時(shí)間為1.92ms,節(jié)點(diǎn)為1時(shí),共減少時(shí)間為(15.5+1.92)*1765*0.9=27672ms,此值與表1表2的測(cè)量值207.2-179.6=27.6s基本符合。
實(shí)驗(yàn)二中,由于采用了支持USB的CC2531,能夠把OTA服務(wù)器返回的鏡像塊響應(yīng)所需時(shí)間縮短為22.5ms,節(jié)點(diǎn)發(fā)送鏡像頁(yè)請(qǐng)求所需時(shí)間保持為15.5ms不變,來(lái)回確認(rèn)幀時(shí)間為5.76ms。當(dāng)鏡像頁(yè)大小為64字節(jié)時(shí),傳輸所需時(shí)間為(22.5+15.5+5.76)*1765=77236ms,也與表3的測(cè)量值77.2基本相符。當(dāng)鏡像頁(yè)大小為6400字節(jié)時(shí)候,即請(qǐng)求命令減少到原來(lái)的百分之一,時(shí)間縮短了50s,更新效率大幅度提高,基本達(dá)到了單個(gè)節(jié)點(diǎn)更新速度的極限。
5. 結(jié)論
介紹了一種基于ZigBee的空中下載技術(shù),非常適用于短距離的無(wú)線(xiàn)傳感網(wǎng)絡(luò)應(yīng)用場(chǎng)合。通過(guò)無(wú)線(xiàn)更新固件,免去了回收更新節(jié)點(diǎn)所需時(shí)間,可以達(dá)到更新完成后不破壞當(dāng)前網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)的效果。另外,在Z-Stack協(xié)議棧設(shè)計(jì)了一種鏡像頁(yè)請(qǐng)求更新方式,實(shí)驗(yàn)結(jié)果表明,當(dāng)批量更新整個(gè)網(wǎng)絡(luò)時(shí),既可以提高節(jié)點(diǎn)的更新效率,又可以大大減少網(wǎng)絡(luò)的更新流量,并節(jié)省節(jié)點(diǎn)的功耗;當(dāng)進(jìn)行點(diǎn)對(duì)點(diǎn)更新時(shí),如果把響應(yīng)間隔縮減為10ms,并把鏡像頁(yè)設(shè)置為足夠大,單個(gè)節(jié)點(diǎn)的更新時(shí)間可以縮減為27.3s,接近單個(gè)節(jié)點(diǎn)更新速度的極限。至于使用批量的更新方式還是點(diǎn)對(duì)點(diǎn)的更新方式,視具體的應(yīng)用場(chǎng)合而定。
評(píng)論
查看更多