高 菲
基于改進代碼分發協議的遠程代碼更新技術研究?
高 菲
(寶雞職業技術學院 寶雞 721000)
首先對經典的代碼分發協議進行改進,控制信息使用Trickle協議進行維護,用于通知整個網絡當前分發的版本信息,利用廣播的形式分發數據,使通信范圍內所有節點都能接收到數據。之后,設計遠程代碼更新系統,將系統分為三個部分,分別為上位機、網關節點以及傳感器節點。重點設計具有代碼更新功能的傳感器節點的軟件,將節點的存儲空間分為引導部分和程序部分,利用不同的存儲器映射進行版本切換。實驗結果表明系統能夠成功完成遠程代碼更新;能夠同時更新多個節點,能夠支持多跳的更新,在發生丟包的情況下,能對丟失數據進行請求,保證傳輸代碼的完整性。
無線傳感器網絡;遠程代碼更新;數據分發;代碼分發
AbstractThis paper aims at improving the classic code distribution agreement,controlling information by the Trickle proto?col for maintenance and version information for the entire network current distributing,through broadcast in the form of a distributed data,which makes communication within the scope of all nodes receiving the data possible.After the remote code update system de?sign,the system is divided into three parts,respectively for PC,the gateway node and sensor node.The key design is softwear which has the function of code updating of sensor nodes.The nodes of the storage space is divided into guiding parts and procedures,using different memory mapping to switch from the version.Experimental results show that the system can successfully complete re?mote code updates,and it can update multiple nodes at the same time,can support multiple hops update.In the event of a lost pack?age,it can also request data loss to ensure the integrity of the transmission code.
Key W ord wireless sensor network,code update,data distribution,code distribution
Class NumberTP393
無線傳感器網絡由大量擁有無線發射模塊的節點組成,節點依據各自的應用環境配備不同的傳感器,利用傳感器采集數據后,以無線的方式傳輸至匯聚節點,以達到遠程監測的目的。節點部署完畢后,很多情況下需要對節點進行代碼更新。遠程代碼更新已成為無線傳感器網絡領域重要的研究課題。目前,國內外研究人員針對遠程代碼更新方法已進行相關研究,研究方向主要為代碼分發以及數據壓縮。若要使用代碼更新技術需要額外的存儲空間,完成代碼更新需要完整的解決方案,因此對遠程代碼更新技術的研究很有必要。
在實現代碼更新的過程中,各個節點需要各自廣播當前節點的版本信息與網絡中的控制信息,以保證整個網絡均能收到網關節點發送的控制消息,并運行在正確的版本上。各節點通過比對版本信息,判定是否需要進行數據交換,完成整個代碼的分發工作。Trickle數據分發協議能夠解決小數據量的分發,可以用于代碼更新過程中控制字以及版本信息的分發。當數據量達到一定規模的情況下,需要使用不同的協議用于完成整段代碼的分發功能。Deluge協議是一種泛洪式的代碼分發協議,即代碼通過廣播的形式,以擴散的方式分發至各個節點。
為適應低功耗、低成本的系統設計,需要對協議進行適當修改。同樣將分發過程分為三個階段:維護階段、RX階段以及TX階段。Deluge協議使用了流水線技術以提高代碼傳播速度,但其提高的程度不高,取消流水線技術,待節點完全接收完畢后再行使分發的功能,從而減輕了接收端的負擔。
Trickle協議可以滿足少量數據分發節點維護過程,使用Trickle協議進行維護,維護的數據包括上位機發送的對全網的控制命令,如節點重啟、版本切換以及代碼分發,同時控制命令包含了待分發網絡的版本信息,通過網絡版本信息與節點當前版本比對,節點即可知道自己應該處于接收還是分發狀態。
更新過程如圖1所示,網絡由4個節點組成,分別為網關節點,傳感器節點A、B、C,其中網關節點與節點A、B在一跳的范圍內,節點C與網關節點相距較遠,無法直接通信。最初各節點處于維護狀態,各節點隨機地廣播ADV消息,以保證全網的版本一致。網關節點從上位機接收到了新版本代碼,需要分發至整個網絡。分發過程如下。
1)網關節點首先利用Trickle協議發送CTL消息,該消息中包含最新版本號以及最新版本文件大小,該消息將會發送至整個網絡。
2)當CTL消息傳播完畢后,各節點將隨機發送ADV消息,ADV消息中包含當前節點的版本信息新版本節點發現舊版本信息后盡快廣播一個ADV消息,讓周圍節點知道該節點版本是最新的。
3)節點A、B接收到網關節點發送的ADV消息,從消息中解析出網關節點有新版本數據可用,隨即進入RX狀態,節點A搶先向網關節點發送了REQ消息。
4)網關節點接收到來自節點A的發送消息后進人TX狀態,廣播DATA數據。
5)節點A、B同時接收到來自網關節點的DA?TA數據,節點B受到抑制,無需再發送REQ消息。
6)節點A、B接收到完整更新數據,重啟節點,重新進入維護狀態,此時節點A、B運行新版本的程序。
7)節點B重啟后,發送ADV消息,由節點C接收到,轉入RX狀態,重復之前節點A、B接收的步驟。

圖1 分發流程
在更龐大的網絡中,更新代碼將一層層的向外擴散,直至整個網絡都運行最新的代碼。在更新過程中,待接收的節點永遠處于接收狀態,直至代碼完全更新完畢對于節點而言,單一的接收、發送狀態,減輕了節點在同一時刻的負擔。
遠程代碼更新系統以硬件進行劃分,可以劃分為三個部分,分別為:上位機、網關節點以及傳感器節點。為了能實現代碼的遠程更新,需要對三部分進行逐一設計,最終使得代碼能完整的從上位機傳至網關節點,再從網關節點分發至整個網絡。
遠程代碼更新過程如圖2所示:在上位機編寫帶有分發協議的基本程序。將基本程序通過串口燒寫至各個節點,各個節點在網絡上正常工作。需要進行代碼更新時,在上位機編寫新的程序,編譯完成后通過串口燒入網關節點。上位機通過串口向網關節點發送分發指令,網關節點收到指令后,將指令消息廣播至整個網絡。節點A、B利用分發協議先接收到完整程序,啟用新版本程序。節點C從節點B接收新版本程序,并重啟更新。

圖2 遠程代碼更新圖
為完成上述的代碼更新過程,需要分別設計上位機軟件、網關節點程序以及節點程序三部分。
上位機軟件使用C#編程,上位機程序共需要完成兩部分功能,首先將iHex文件發送至網關節點,其次需要給網關節點發送控制命令,控制整個網絡的分發狀態。
網關節點使用C編程,負責接收上位機發送的新版本程序,接收上位機發送的控制命令。做出相應的響應。解析上位機發送新版本程序的命令,負責將新版本程序分發至各個傳感器節點。傳感器節點的程序又分為兩個部分,啟動引導部分與運行程序部分。啟動引導部分負責各版本之間的切換工作,在分發過程中,程序會對版本啟動信息進行修改,在啟動過程中讀取啟動信息,跳轉到特定版本的運行程序。運行程序包含正常的采集數據或其他節點功能程序,還包含了分發協議。在運行過程中,節點功能程序與分發協議互不干擾。
節點代碼分發協議與網關節點使用的協議一致,傳感器節點在模塊部分相比網關節點減少了串口接收功能。分發協議主要模塊如圖3所示,總模塊利用Trickle接收到的信息進行判定分發方式,Object分發模塊負責對整個版本的分發或接收,調用頁分發模塊進行每一頁的分發或接收,當新版本程序接收完成后進行重啟。新版本程序裝入節點,并成功重啟后,將作為分發節點,將新版本程序分發到更遠的節點。

圖3 代碼分發模塊
分發總模塊為分發協議最頂層的模塊,控制整個協議的工作狀態。在節點啟動初始化完畢后。將調用Trickle分發模塊,開啟Trickle分發功能,用于維護一段控制信息,該信息包括控制命令、分發代碼的版本號以及分發代碼的大小。
typedef nx_struct DelugeCmd{
nx_uint8_t type;
nx_uint8_t uidhash;
nx_uintl6_t size;
}DelugeCmd;
在維護階段,節點周期性的廣播該信息,以保證全網信息一致。當Trickle模塊從其他節點接收到新的控制消息時,將會以事件的方式通知分發總模塊有新消息,分發總模塊對該事件進行響應。分發模塊讀取新消息的控制字,節點收到的控制命令有兩種情況,分別為停止分發和分發。
當節點接收到停止分發命令,則調用Object分發模塊的接口停止代碼分發,Object分發模塊再調用頁模塊的接口停止當前頁分發操作,最終整個程序停止分發或接收代碼。
當節點接收到分發指令后,需要讀取分發指令的程序版本號以及程序大小。將讀取到的版本號與自身的版本號進行比對,決定該節點是處于接收狀態還是分發狀態。調用Object分發模塊的pub?lish或receive接口,使程序進入接收或分發狀態。調用方式如下。
task void taskRequest(){
switch(state){
case S_PUB:
call ObjectTransfer.publish(lastCmd.uidhash,lastC?md.size);
break;
case SRECV:
call ObjectTransfer.receive(lastCmd.uidhash,lastCmd.size,bootArgs.bootBank);
break;}}
收到版本信息后,會設置當前節點狀態。并且在任務隊列中加入taskReguest任務,任務的調度方式是先進先出的,用于處理對時間要求不高的事務。對于分發任務,需要傳遞代碼版本號以及代碼大小的參數。對于接收任務,需要額外傳遞啟動Bank號的信息,通過當前啟動版本所在Bank位置的信息,決定新版本程序存放位置。
Object分發模塊管理整個代碼的分發或接收進度,全網廣播消息,使各節點完成各自的分發或接收工作。該模塊提供的接口被分發總模塊調用,向總模塊提供分發、接收和停止的功能,在同一時刻,節點僅可能有一種狀態,即分發、接收或停止。當接收到停止指令時,停止一切消息的傳輸,并調用頁模塊的接口,使得頁模塊也停止傳輸數據,等待下一步的命令。
在該模塊中周期性地廣播ADV消息,與Trick?le維護的消息不同,該消息除了包含代碼版本號和代碼大小外,還包含了當前節點已完成的頁數。通過已完成頁數,可判斷出該節點是處于接收還是分發模式。
typedef nx_struct ObjDesc{
nx_object id t objid;
nx_page num_t numPgs;
nx_age_num_t numPgsComplete;
}ObjDesc;
若節點接收到其他節點廣播的ADV消息,通過收到的ADV消息判斷廣播節點與當前節點的狀態是否一致,如果狀態一致,即同時處于分發狀態或同時處于接收狀態,則抑制本輪廣播,并且當節點多次抑制廣播信息后,將延長廣播周期,以節省能耗。
若分發節點接收到由接收節點廣播的ADV消息,則繼續等待定時器的觸發,廣播當前ADV消息,以使得接收節點可以從當前節點獲取新版本信息。若接收節點接收到由分發節點廣播的ADV消息,則調用頁模塊提供的接口,準備請求接收需要接收的頁,接收節點每次僅請求接收一頁消息。Object分發模塊管理著當前節點已接收到的頁數,有分發節點時調用頁模塊接口請求接收下一頁。頁模塊完成一整頁的接收后,會通知Object分發模塊,Object分發模塊將完成頁數加一,等待ADV消息再請求接收下一頁。
在程序的分發過程中,以頁為一個單位進行傳輸,定義每個頁的大小為1024個字節。Object分發模塊負責管理當前程序以完成的頁數,頁分發模塊完成對某一頁的發送或接收操作。將程序分割成頁后,由于1024字節大小依舊超出了無線傳輸包的字節限制,需要使用位圖對數據包進行管理。
定義一個byte類型數組pktsToReceive[N],該數組的總位數表示一頁中共有多少數據包等待傳輸,例如一個包中可以裝100個字符的數據,則每一頁需要傳輸11個包,則此處N為2,數組中共有16位。數組中的每一位代表一個數據包是否接收,作為接收節點,將該數組包含在REQ消息中,向分發節點REQ消息。分發節點接收到REQ消息后,查看其中的請求頁號以及pktsToReceive數組,得知接收節點需要的數據部分,分發節點從Flash中讀取應分發的數據,并且進行廣播發送。
頁分發模塊負責傳輸和接收兩種消息,分別為請求消息與數據消息。
typedef nx_struct DelugeReqMsg{
nx_uintl6_t dest;
nx_uintl6_t sourceAddr;
nx_object_id_t objid;
nx_page_num_t pgNum;
nx_uint8_t requestedPkts[DELUGET2-KTes BIT?VEC_SIZE];
}DelugeReqMsg;
請求消息包含了請求節點的地址、目的地址、請求的版本號、頁號以及位圖信息。
typedef nx_struct DelugeDataMsg{
nx_object_id_t objid;
nx_page_num_t pgNum;
nx_uint8_t pktNum;
nx_uint8_t data[DELUGET2 PKT_PAYLOAD SIZE];
}DelugeDataMsg;
數據消息包含了發送的版本號、頁號、數據包號以及數據信息。
頁分發模塊同樣有三種狀態,分別為分發、接收和停止狀態,其狀態與Object分發模塊的狀態一致,當Object分發模塊狀態發生改變時,頁分發模塊的狀態也會隨之改變。
接收狀態下,頁分發模塊完成兩個功能。分別為數據請求與數據接收。每當Object分發模塊得知有其他新版本節點時,將告知頁分發模塊,頁分發模塊準備向新版本節點請求接收數據。由于可能有多個節點同時得知網絡中存在新版本節點防止多個節點同時向新版本節點發送請求數據,節點經過一段隨機時間的延時后再向新版本節點發送請求。無論是否發送了請求數據,各節點均能接收到來自新版本節點的廣播數據,判斷該數據是否為當前節點需要的數據,若需要該數據則寫入Flash,并且抑制當前即將發送的請求。當節點接收到待接收頁的完整數據后,通知Object分發模塊,并將待接收頁設置為下一頁。分發狀態下,等待接收其他節點發送的請求數據。當接收到其他節點的請求,分析請求信息,準備請求信息中需求的數據,由于請求的數據可能需要多個數據包才能傳輸完畢,逐步廣播所有需要發送的數據包,在完整數據發送完成前,忽略其他節點的請求。
采用一個網關節點、多個傳感器節點進行實驗。傳感器節點分布在網關節點周圍。且傳感器節點可直接與網關節點進行通信。分發代碼的大小為26.65KB,傳感器節點數量從一個逐步增加至二十個。其位置示意圖如圖4所示,網關節點通過上位機接收指令,進行分發,傳感器節點均勻分布在網關節點周圍,且能相互通信。

圖4 單跳節點位置示意圖
圖5 表示了分發至不同數量節點所需使用的時間。當更新一個節點時需使用的時間為139s,隨著節點數量的增多,分發時間略有下降,時間穩定在115s左右。由于發送REQ的等待時間是隨機的,當節點數量增多,總體REQ時間會相對減小,從而分發速度變得更快了。且當網絡中發生丟包的情況,當一個節點接收到了ADV消息。而另一個節點沒接收到的情況下。依舊能夠有一個節點向網關節點發REQ消息。而不會等待網關節點發送第二次的ADV消息,同樣加快了分發速度。

圖5 節點更新時間
當傳感器節點數量增加到12個后,分發速度顯著下降。由于無線信道的穩定性相對有線傳輸較差,當節點增多時,丟包的可能性增大,即重傳的次數增多,導致分發速度下降。大量節點同步更新的過程中。若有某個節點A未接收到某個數據包,其請求信息可能會淹沒在其他節點中,即其他節點搶先向網關節點請求數據包。其他節點請求的數據包不是節點A可用的數據,導致該節點無法直接從網關節點偷聽得到數據,需等到其他節點完全更新完畢后,才能從之前丟失數據的地方繼續接收新的數據。單個節點的數據包丟失,將使得整個網絡的更新時間變得更長,當無線信道環境足夠理想時,如更新19個傳感器節點的情況,其更新速度與更新節點數量無關。
多跳實驗中,各節點以圖6方式進行放置,網關節點放置于實驗室房間內,傳感器節點A放置于門口,傳感器節點B放置于走廊。傳感器節點A可與網關節點或傳感器節點B直接通信,網關節點與傳感器節點B不能直接進行通信,代碼分發需要通過傳感器節點B進行分發。在更新過程中,首先需要將代碼分發至傳感器節點A,再由傳感器節點A將代碼分發至傳感器節點B,待更新代碼的大小同樣為26.65KB數據。

圖6 多跳節點位置示意圖
分發過程中,為了構成多跳的網絡,將節點布置在距離較遠的位置,由于接收信號強度較弱,更易受到干擾,因此丟包的概率顯著提升,觀察偵聽軟件偵聽到的數據包可發現,傳感器節點A多次向網關節點發送了重發的請求。在經過220s后,完成了從網關節點傳輸至傳感器節點A的更新。又經過了500s,最終完成了全部的更新,總共經歷了720s。
在傳感器節點A與傳感器節點B旁各放置一個節點,同樣為一跳,多跳網絡完整更新的時間縮短為480s,相比2個傳感器節點的更新速度有顯著提升。當節點增多時,收到包的概率也相對增加,從而縮短了更新所用的時間。多跳網絡的理想更新時間應為當前網絡跳數乘以單跳網絡的時間,未達到理想速度估計是由于無線信道的不穩定,常有丟包出現,當數據無法正常傳輸至節點,更新時間將會延長。
無線傳感器網絡,是近幾年來計算機技術方面的熱門研究對象之一,而遠程代碼更新技術是無線傳感器網絡的一個重要技術,利用遠程代碼更新技術,可以減少不必要的重復性操作,且對特殊環境下的程序調整尤為重要。本文是無線傳感器網絡遠程代碼更新的系統設計方法研究,并進行系統的實現。通過研究各協議,完成無線傳感網絡遠程代碼更新的設計,更新程序能準確無誤的分發至各個節點。
[1]Kulkarni S S,Wang L.MNP:Multihop Network Repro?gramming Service for Sensor Networks[C]//IEEE Interna?tional Conference on Distributed Computing Systems,2005.ICDCS 2005.Proceedings.IEEE,2005:285-286.
[2]Kulkarni S,Wang L.Energy-efficient multihop repro?gramming for sensor networks[J].Acm Transactions on Sensor Networks,2009,5(2):1-40.
[3]Rossi M,Bui N,Zanca G,et al.SYNAPSE++:Code Dis?semination in Wireless Sensor Networks Using Fountain Codes[J].IEEE Transactions on Mobile Computing,2010,9(12):1749-1765.
[4]Gao Y,Bu J,Dong W,et al.Exploiting Concurrency for Efficient Dissemination in Wireless Sensor Networks[C]//International Conference on Distributed Computing in Sen?sor Systems and Workshops.IEEE,2011:1-8.
[5]ZHAO.Integrated mutual selection based code dissemina?tion for reprogramming wireless sensor networks[J].Jour?nal of China Universities of Posts&Telecommunications,2013,20(1):79-84.
[6]Dong W,Liu Y,Zhao Z,et al.Link Quality Aware Code Dissemination in Wireless Sensor Networks[J].IEEE Transactions on Parallel&Distributed Systems,2014,25(7):1776-1786.
[7]Alam SM I,Sultana S,Hu Y C,et al.SYREN:Synergis?tic Link Correlation-Aware and Network Coding-Based Dissemination in Wireless Sensor Networks[C]//IEEE,International Symposium on Modeling,Analysis&Simula?tion of Computer and Telecommunication Systems.IEEE,2014:485-494.
[8]Kim D,Nam H,Kim D.Adaptive Code Dissemination Based on Link Quality in Wireless Sensor Networks[J].IEEE Internet of Things Journal,2016,PP(99):1-1.
[9]Concepts R.Wireless sensor networks:a survey[J].Com?puter Networks the International Journal of Computer&Telecommunications Networking,2014,38(4):393-422.
[10]Levis P,Madden S,Polastre J,et a1.TinyOS:An oper?ating system for sensor networks[J].Ambient Intelli?gence,2004:383-396.
[11]Li J,Wang F,Duan W Research of TinyOS in Wireless Sensor Networks[J].Computer Measurement&Control,2006,14(6):838-840.
Research of Rem ote Code Update Technology Based on the Im proved Code Distribution Agreement
GAO Fei
(Baoji Vocational Technology College,Baoji 721000)
TP393
10.3969/j.issn.1672-9722.2017.09.029
2017年3月13日,
2017年4月20日
高菲,女,碩士研究生,研究方向:計算機教育。