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