ZigBee空中技術(shù)研究及其優(yōu)化設(shè)計(jì)-技術(shù)方案

精品文檔-下載后可編輯ZigBee空中技術(shù)研究及其優(yōu)化設(shè)計(jì)-技術(shù)方案引言

本文移植并驗(yàn)證了一種基于ZigBee協(xié)議的空中（OTA）技術(shù)，其分發(fā)協(xié)議支持點(diǎn)對多傳輸更新功能，多跳網(wǎng)絡(luò)的代碼分發(fā)功能由路由協(xié)議支撐。在Z-Stack協(xié)議棧下，僅僅支持鏡像塊請求功能，更新效率并不理想。針對此問題，設(shè)計(jì)出一種高效的鏡像頁請求功能，能夠提高點(diǎn)對多的傳輸更新效率，并減少網(wǎng)絡(luò)流量。

1OTA概述

ZigBee協(xié)議規(guī)范使用了IEEE802.15.4定義的物理層（PHY）和媒體介質(zhì)訪問層（MAC），并在此基礎(chǔ)上定義了網(wǎng)絡(luò)層（NWK）和應(yīng)用層（APL）。針對無線傳感網(wǎng)絡(luò)重編程技術(shù)的需求，ZigBee聯(lián)盟在原有協(xié)議的框架上，提出了一種OTA規(guī)范，其作為一個系統(tǒng)可選的功能模塊。OTA系統(tǒng)的結(jié)構(gòu)示意圖和服務(wù)器與客戶端之間的數(shù)據(jù)交互過程略--編者注。

2OTA系統(tǒng)設(shè)計(jì)

本文的OTA系統(tǒng)基于TI公司的ZigBeeSoC芯片CC2530F256設(shè)計(jì)，包括硬件與軟件的設(shè)計(jì)。

2.1硬件系統(tǒng)

CC2530F256內(nèi)部集成一個增強(qiáng)型8051單片機(jī)，擁有8KBSRAM和256KB內(nèi)部Flash存儲器。內(nèi)部Flash主要用來保存程序代碼和常量數(shù)據(jù)。由于傳統(tǒng)8051代碼存儲空間尋址范圍只有64KB,CC2530把內(nèi)部256KBFlash分成8個bank,每一個bank大小是32KB,通過寄存器FMAP.MAP[2:0]選擇不同的bank映射到代碼存儲空間，解決了尋址空間受限的問題。

對于OTA客戶端，啟動代碼位于bank0的0x0000~0x0800地址區(qū)域，大小為2KB.其余的254KB的Flash空間，用來存儲當(dāng)前固件和其他信息。值得注意的是，0x0888~0x088B區(qū)域存放了CRC校驗(yàn)信息，0x088C~0x0897區(qū)域存放了PREAMBLE,包括鏡像大小、制造商ID、鏡像類型和鏡像版本號信息。另外，bank7的14KB空間（0x7C800~0x7FFFF）用作非易失性（NoneVolatile,NV）變量區(qū)（12KB）和特定信息保留區(qū)（2KB）。

OTA系統(tǒng)升級方案有兩種，分別是片內(nèi)Flash升級和片外Flash升級?？紤]到一般程序固件大小都超過128KB和以后程序功能升級的擴(kuò)展性，本文采用片外Flash的方案。采用的片外Flash（M25PE20）容量為256KB,通過SPI總線與CC2530之間傳輸數(shù)據(jù)。

2.2軟件系統(tǒng)

對于基于任務(wù)事件輪詢機(jī)制的Z-Stack工程，默認(rèn)沒有添加OTA功能。如果節(jié)點(diǎn)需要開啟OTA功能，首先需要燒寫OTA的啟動代碼。當(dāng)節(jié)點(diǎn)完成鏡像接收之后，對新鏡像進(jìn)行CRC校驗(yàn)，并清空當(dāng)前鏡像的CRC信息，然后重啟。當(dāng)節(jié)點(diǎn)重啟后，首先跳轉(zhuǎn)到啟動代碼的地址，開始執(zhí)行如圖1所示的工作流程。

3OTA的鏡像頁請求實(shí)現(xiàn)

根據(jù)ZigBeeOTA的規(guī)范，OTA客戶端向OTA服務(wù)器請求鏡像的方式有兩種，分別是鏡像塊請求與鏡像頁請求。鏡像塊請求的OTA更新方式效率較低。

本文根據(jù)ZigBeeOTA的規(guī)范，在Z-Stack協(xié)議棧上設(shè)計(jì)出鏡像頁請求的更新方式。頁請求命令與塊請求命令類似，在數(shù)據(jù)幀當(dāng)中附加了鏡像頁大小與響應(yīng)間隔信息。當(dāng)OTA服務(wù)器收到頁請求后，在一定時間間隔內(nèi)多次向節(jié)點(diǎn)發(fā)送塊響應(yīng)，免去了多次塊請求。其中，塊響應(yīng)的次數(shù)由鏡像頁大小決定，時間間隔由響應(yīng)間隔設(shè)定。正因?yàn)檎埱竺畹匿J減，能夠大大減輕整個網(wǎng)絡(luò)流量的負(fù)擔(dān)，并提高節(jié)點(diǎn)的傳輸更新效率。

Z-Stack運(yùn)行在一個OSAL操作系統(tǒng)上，OSAL是一種基于任務(wù)事件調(diào)度機(jī)制的操作系統(tǒng)。每個任務(wù)包含若干事件，每個事件對應(yīng)一個事件號。當(dāng)一個事件需要產(chǎn)生時，可以通過API函數(shù)設(shè)置相應(yīng)的事件號，然后提交給操作系統(tǒng)調(diào)度觸發(fā)。本文設(shè)計(jì)的鏡像頁請求功能正是基于這種機(jī)制。OTA服務(wù)器的鏡像頁請求處理流程如圖2所示，OTA服務(wù)器為每一個請求更新的節(jié)點(diǎn)分配一個事件號，并通過請求節(jié)點(diǎn)的短地址索引，設(shè)置特定的事件。進(jìn)入事件后，OTA服務(wù)器通過串口向OTA應(yīng)用控制臺請求鏡像數(shù)據(jù)塊，并向節(jié)點(diǎn)發(fā)送鏡像塊數(shù)據(jù)。通過把事件添加到定時器鏈表，就能夠以響應(yīng)間隔為時間單位，循環(huán)發(fā)送鏡像塊數(shù)據(jù)，直到累計(jì)的發(fā)送鏡像塊大小等于節(jié)點(diǎn)的請求鏡像頁大小，從而完成鏡像頁請求的傳輸過程。

Z-Stack協(xié)議棧有一個MAC定時器為操作系統(tǒng)提供計(jì)時。該定時器以每1ms為單位，更新系統(tǒng)的定時器事件鏈表。定時器事件鏈表如圖3所示，鏈表的每一個結(jié)點(diǎn)記錄了任務(wù)號（task_id）、事件號（event_flag），計(jì)時時間（timeout）和下一個結(jié)點(diǎn)地址（*next）。圖中的ZCL_OTA_MT_READn定義為每個請求節(jié)點(diǎn)對應(yīng)的事件號，ResponseSpacing即為節(jié)點(diǎn)請求的響應(yīng)間隔，把兩者添加到鏈表當(dāng)中。當(dāng)計(jì)時時間減為0后，系統(tǒng)自動設(shè)定對應(yīng)的事件號，從而使OTA服務(wù)器循環(huán)地向OTA應(yīng)用控制臺索取鏡像塊數(shù)據(jù)，并向節(jié)點(diǎn)發(fā)送鏡像塊響應(yīng)。

OTA服務(wù)器處理鏡像頁請求的部分代碼段如下：

4驗(yàn)證與分析

4.1功能驗(yàn)證

為了驗(yàn)證OTA功能，在CC2530F256平臺上搭建一個小型樹狀網(wǎng)絡(luò)，并使用PacketSniffer對OTA更新時的節(jié)點(diǎn)進(jìn)行抓包分析。4個傳感節(jié)點(diǎn)的固件并沒有添加溫度采集功能，所以溫度顯示為0.在新的固件中添加了溫度采集函數(shù)，用于驗(yàn)證OTA更新成功。

對于某些特定應(yīng)用，需要節(jié)點(diǎn)更新固件后能夠保持原來的網(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ù)原來網(wǎng)絡(luò)信息。

對4個傳感節(jié)點(diǎn)進(jìn)行OTA更新。OTA更新后，溫度采集功能成功添加，而且傳感節(jié)點(diǎn)的網(wǎng)絡(luò)短地址沒有發(fā)生變化，網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)保持完整，驗(yàn)證了進(jìn)行OTA鏡像升級過程中，并不會對NV區(qū)進(jìn)行擦除，有利于節(jié)點(diǎn)網(wǎng)絡(luò)信息的恢復(fù)。

OTA服務(wù)器被配置為路由器（0x06BC），對傳感節(jié)點(diǎn)（0x0002）進(jìn)行點(diǎn)對點(diǎn)更新。條短幀是子路由向OTA服務(wù)器發(fā)送ImageBlockRequest,應(yīng)用層載荷從第4字節(jié)開始記錄了新鏡像的制造商ID（0x5678）、鏡像類型（0x1234）、版本號（0x00000002）和鏡像塊偏移量。1個字節(jié)記錄了每次傳送鏡像塊大小（OTA_MAX_MTU），默認(rèn)為0x20,即為32字節(jié)。第二條長幀是OTA服務(wù)器發(fā)送的ImageBlockResponse,載荷記錄格式與前者類似，并在鏡像塊大小字節(jié)后面附上32字節(jié)鏡像塊信息，從而完成一個鏡像塊傳輸周期。

4.2效率分析

搭建一個星形網(wǎng)絡(luò)，把OTA服務(wù)器配置成協(xié)調(diào)器，把所有OTA客戶端配置成節(jié)點(diǎn)，并進(jìn)行如下兩個實(shí)驗(yàn)。

4.2.1實(shí)驗(yàn)一

為了對比分析兩種更新手段的效率，分別使用鏡像塊請求命令與鏡像頁請求命令，對節(jié)點(diǎn)進(jìn)行OTA更新。星形網(wǎng)絡(luò)中，通過廣播ImageNotify,能夠?qū)Χ喙?jié)點(diǎn)進(jìn)行批量更新。網(wǎng)絡(luò)規(guī)模分別為1~6個節(jié)點(diǎn)，測量了不同規(guī)模網(wǎng)絡(luò)下節(jié)點(diǎn)完成更新傳輸所需的時間。Min與Max分別指快與慢完成更新傳輸?shù)墓?jié)點(diǎn)對應(yīng)的時間，Ave指平均每個節(jié)點(diǎn)完成更新傳輸所需時間（使用Max值計(jì)算）。

其中，鏡像頁請求設(shè)置的ResponseSpacing為100ms,鏡像頁大小為640字節(jié)。鏡像大小統(tǒng)一為113KB,并修改OTA_MAX_MTU大小為64字節(jié)。節(jié)點(diǎn)與OTA服務(wù)器間隔均為5m.鏡像塊、鏡像頁請求的傳輸時間分別如表1、表2所列，響應(yīng)間隔均為100ms.

實(shí)驗(yàn)一中，使用鏡像塊請求，節(jié)點(diǎn)發(fā)送鏡像塊請求所需時間為15.5ms,OTA服務(wù)器返回鏡像塊響應(yīng)所需時間實(shí)際為96ms,來回確認(rèn)幀時間大概為1.92+3.84=5.76ms.一個更新周期傳輸鏡像塊大小為64字節(jié)，完成113KB大小的鏡像傳送需要1765個周期。總時間為（96+15.5+5.76）×1765=206963ms,這與表1中的測量值207.2s基本符合。

本文設(shè)計(jì)的鏡像頁請求中鏡像頁大小為640字節(jié)，每次傳輸鏡像塊大小為64字節(jié)，即節(jié)點(diǎn)發(fā)送1次頁請求可以得到10次塊響應(yīng)。當(dāng)更新1個節(jié)點(diǎn)時，使用鏡像頁請求可以把原來的1765條請求命令和1765條確認(rèn)幀減少9/10,共減少3177條傳輸幀。減少的傳輸幀數(shù)量隨著節(jié)點(diǎn)數(shù)目成比例增長。

對比表1與表2,可以發(fā)現(xiàn)無論節(jié)點(diǎn)數(shù)目為多少，頁請求的平均每個節(jié)點(diǎn)的更新傳輸時間都比塊請求的要短。其中，發(fā)送鏡像頁請求時間為15.5ms,請求確認(rèn)幀時間為1.92ms,節(jié)點(diǎn)為1時，共減少時間為（15.5+1.92）×1765×0.9=27672ms,此值與表1和表2的測量值207.2-179.6=27.6s基本符合。

4.2.2實(shí)驗(yàn)二

為了測試鏡像頁請求在點(diǎn)對點(diǎn)更新情況下的效率，設(shè)定短的響應(yīng)間隔為10ms,分別測量不同鏡像頁大小的單個節(jié)點(diǎn)更新傳輸時間。使用CC2531（支持USB）作為OTA服務(wù)器，能夠縮短服務(wù)器向應(yīng)用控制臺索取鏡像塊數(shù)據(jù)的時間，進(jìn)一步加快更新傳輸效率。鏡像大小統(tǒng)一為113KB,OTA_MAX_MTU大小為64字節(jié)，節(jié)點(diǎn)與OTA服務(wù)器間隔均為5m.不同鏡像頁大小下的傳輸時間如表3所列。

實(shí)驗(yàn)二中，由于采用了支持USB的CC2531,能夠把OTA服務(wù)器返回的鏡像塊響應(yīng)所需時間縮短為22.5ms,節(jié)點(diǎn)發(fā)送鏡像頁請求所需時間保持為15.5ms不變，來回確認(rèn)幀時間為5.76ms.當(dāng)鏡像頁大小為64字節(jié)時，傳輸所需時間為（22.5+15.5+5.76）×1765=77236ms,也與表3中的測量值77.2s基本相符。當(dāng)鏡像頁大小為6400字節(jié)時，即請求命令減少到原來的1/100,時間縮短了50s,更新效率大幅度提高，基本達(dá)到了單個節(jié)點(diǎn)更新速度的極限。

結(jié)語

通過無線更新固件，免