嵌入式多節(jié)點(diǎn)的無線批量程序更新系統(tǒng)設(shè)計(jì)(二)
掃描二維碼
隨時(shí)隨地手機(jī)看文章
3.2 可靠數(shù)據(jù)分發(fā)協(xié)議的設(shè)計(jì)
在闡述具體的設(shè)計(jì)思路之前,先提出以下應(yīng)用場(chǎng)景的假設(shè)。
假設(shè)一:網(wǎng)絡(luò)節(jié)點(diǎn)不支持高級(jí)的操作系統(tǒng)??梢岳斫鉃楸仨毧紤]節(jié)點(diǎn)處理和通信能力有限,而且通信協(xié)議要從底層(如MAC層)實(shí)現(xiàn)。
假設(shè)二:大部分待燒錄節(jié)點(diǎn)分布在數(shù)據(jù)基站的通訊范圍之內(nèi)。可以理解為通信協(xié)議不需要實(shí)現(xiàn)復(fù)雜的多跳通信和流水線,可以充分利用數(shù)據(jù)基站第一次數(shù)據(jù)廣播,這一點(diǎn)下文會(huì)詳細(xì)闡述。
基于以上兩點(diǎn)假設(shè),可靠性數(shù)據(jù)分發(fā)協(xié)議的具體設(shè)計(jì)如下。
考慮到不同平臺(tái)的無線收發(fā)模塊提供的服務(wù)接口和通信質(zhì)量的差異以及程序更新對(duì)網(wǎng)絡(luò)可靠性的要求,通信協(xié)議選擇在網(wǎng)絡(luò)層實(shí)現(xiàn)可靠數(shù)據(jù)分發(fā)的機(jī)制,協(xié)議只需要硬件平臺(tái)在MAC層提供收發(fā)數(shù)據(jù)幀的應(yīng)用接口即可。協(xié)議中,數(shù)據(jù)分發(fā)分為兩個(gè)階段:第一輪發(fā)送階段和節(jié)點(diǎn)間交流階段。圖4.2為兩個(gè)階段通信方式示意圖。
(實(shí)線代表發(fā)送完整數(shù)據(jù)文件,虛線表示發(fā)送數(shù)據(jù)頁)
1、第一輪發(fā)送階段。
數(shù)據(jù)基站(如PC)在接收節(jié)點(diǎn)準(zhǔn)備好后不間斷廣播數(shù)據(jù)幀,直至數(shù)據(jù)發(fā)送結(jié)束;接收節(jié)點(diǎn)盡力接收數(shù)據(jù),并記錄自己已有數(shù)據(jù)幀的id信息,期間不向源節(jié)點(diǎn)發(fā)送反饋信息。
在原始的Deluge協(xié)議中沒有這一階段,因?yàn)镈eluge協(xié)議中可能無線傳感器網(wǎng)絡(luò)龐大,分布范圍也較廣,所以數(shù)據(jù)分發(fā)一旦啟動(dòng),所有接收到數(shù)據(jù)的節(jié)點(diǎn)都參與到數(shù)據(jù)發(fā)送中來;而本設(shè)計(jì)中,網(wǎng)絡(luò)充分利用了假設(shè)二中的節(jié)點(diǎn)分布條件,通常情況下,在第一輪發(fā)送結(jié)束后,相當(dāng)大比例的節(jié)點(diǎn)就已經(jīng)接收到了大部分的數(shù)據(jù),而這個(gè)過程中因?yàn)橹挥袛?shù)據(jù)基站在發(fā)送廣播,網(wǎng)絡(luò)中數(shù)據(jù)傳輸?shù)男适亲罡叩?。?dāng)然,這種節(jié)點(diǎn)分布條件不滿足的情況也不會(huì)明顯降低數(shù)據(jù)分發(fā)效率。
節(jié)點(diǎn)間交流階段。
交流階段參考了trickle算法的“polite gossip”策略,所有節(jié)點(diǎn)(包括數(shù)據(jù)基站)都參與到交流中去。每個(gè)節(jié)點(diǎn)的交流的目的都是相同的,即將自己擁有的數(shù)據(jù)包發(fā)送給需要的節(jié)點(diǎn)和請(qǐng)求并接收自己需要的數(shù)據(jù)包。
第2階段是保證可靠性的關(guān)鍵,協(xié)議中讓源節(jié)點(diǎn)也參與到交流中來,這是為了防止網(wǎng)絡(luò)狀況極差以至在第一輪發(fā)送結(jié)束之后所有節(jié)點(diǎn)接收數(shù)據(jù)的總和都不構(gòu)成完整數(shù)據(jù)文件的極端情況。這一步中,節(jié)點(diǎn)長時(shí)間處于“維護(hù)”狀態(tài)標(biāo)志數(shù)據(jù)分發(fā)結(jié)束。
節(jié)點(diǎn)首先廣播廣告,每一個(gè)廣告包含一個(gè)摘要(φ),摘要(φ)由兩部分組成:(1)本節(jié)點(diǎn)的IP標(biāo)識(shí)v。(2)本節(jié)點(diǎn)的最大可用頁號(hào)p,即φ(v,p)??捎庙撎?hào)p的定義:頁p所包含的包被節(jié)點(diǎn)全部接收,稱頁p完成。頁p被完成并且它之前的所有的頁(0,p)也被節(jié)點(diǎn)全部接收,稱頁p可用。節(jié)點(diǎn)通過廣告來了解對(duì)方擁有的數(shù)據(jù)信息,繼而向比自己數(shù)據(jù)更完備的節(jié)點(diǎn)發(fā)送數(shù)據(jù)頁請(qǐng)求。協(xié)議中將時(shí)間分成時(shí)間片(round),在每一個(gè)時(shí)間片中,節(jié)點(diǎn)來決定是否廣播一個(gè)廣告。假設(shè)時(shí)間片的長度由Tm,i來表示,它的上下界由Tl和Th來表示,則有取Tl
交流階段中,節(jié)點(diǎn)擁有“維護(hù)”、“請(qǐng)求”和“發(fā)送”中的人一個(gè)狀態(tài)。節(jié)點(diǎn)在“維護(hù)”狀態(tài)廣播廣告并聽取其他節(jié)點(diǎn)的廣播;在請(qǐng)求階段向其他節(jié)點(diǎn)發(fā)送數(shù)據(jù)頁請(qǐng)求,并接收對(duì)方發(fā)來的數(shù)據(jù);在發(fā)送狀態(tài)廣播被請(qǐng)求的數(shù)據(jù)頁。圖4.3為狀態(tài)轉(zhuǎn)換示意圖。主要的交流規(guī)則如下。
(1)“維護(hù)”狀態(tài)規(guī)則
M1: 假設(shè)時(shí)間片i的開始時(shí)間為ti,節(jié)點(diǎn)在ti+ri的時(shí)間段內(nèi),若接收不到廣告φ'=φ,則廣播廣告φ;若收到與φ不一致的廣告(包括φ'=φ、廣告幀和數(shù)據(jù)幀等),則調(diào)整時(shí)間片為Tl,并立即重新開始時(shí)間片;若接收到廣告φ'=φ,則調(diào)整時(shí)間片為min(2*Tm,i ,Th )。
M2: 節(jié)點(diǎn)在收到廣告φ'(v',p')中p'大于自身的最大可用頁p時(shí),轉(zhuǎn)向“請(qǐng)求”狀態(tài),向節(jié)點(diǎn)v'發(fā)送數(shù)據(jù)頁請(qǐng)求;節(jié)點(diǎn)收到請(qǐng)求幀,則轉(zhuǎn)向“發(fā)送”狀態(tài),廣播被請(qǐng)求數(shù)據(jù)頁。
規(guī)則1能控制冗余廣告的發(fā)送,節(jié)約網(wǎng)絡(luò)資源,并且根據(jù)網(wǎng)絡(luò)狀況動(dòng)態(tài)調(diào)整時(shí)間片長度,從而是網(wǎng)絡(luò)資源得到有效的利用。
規(guī)則2實(shí)現(xiàn)從“維護(hù)”狀態(tài)到“請(qǐng)求”和“發(fā)送”狀態(tài)的轉(zhuǎn)換。
(2)“請(qǐng)求”狀態(tài)規(guī)則:
M3:若節(jié)點(diǎn)在向源節(jié)點(diǎn)發(fā)出數(shù)據(jù)頁請(qǐng)求后節(jié)點(diǎn)在時(shí)間t(t為自定義時(shí)間長度,是經(jīng)驗(yàn)值,根據(jù)網(wǎng)絡(luò)狀況而定)內(nèi)沒有收到數(shù)據(jù),則再次發(fā)送請(qǐng)求,若累計(jì)請(qǐng)求次數(shù)大于k(k為自定義次數(shù)),則認(rèn)為請(qǐng)求失敗,返回“維護(hù)”狀態(tài);若節(jié)點(diǎn)接收到數(shù)據(jù)頁,則在接收結(jié)束后返回“維護(hù)”狀態(tài)。
規(guī)則3中考慮到網(wǎng)絡(luò)的質(zhì)量因素,定義了等待時(shí)間t和最大請(qǐng)求次數(shù)k。
(3)“發(fā)送”狀態(tài)規(guī)則:
M4:節(jié)點(diǎn)進(jìn)入“發(fā)送”狀態(tài)立即廣播被請(qǐng)求的數(shù)據(jù)頁,廣播結(jié)束后返回“維護(hù)”狀態(tài)。
規(guī)則4中要注意的是,節(jié)點(diǎn)以廣播的方式發(fā)送數(shù)據(jù),這意味著處于“請(qǐng)求”狀態(tài)的節(jié)點(diǎn)可以接收任何節(jié)點(diǎn)(不一定是它請(qǐng)求的指定節(jié)點(diǎn))發(fā)送的符合其需要的數(shù)據(jù)包,這也是協(xié)議中避免網(wǎng)絡(luò)冗余的一個(gè)體現(xiàn)。
以上是本設(shè)計(jì)中可靠數(shù)據(jù)分發(fā)協(xié)議的全部內(nèi)容,本文在下一節(jié)中將詳細(xì)論述協(xié)議的軟件設(shè)計(jì)實(shí)現(xiàn)。
3.3 可靠數(shù)據(jù)分發(fā)協(xié)議的軟件設(shè)計(jì)實(shí)現(xiàn)
協(xié)議的軟件設(shè)計(jì)在網(wǎng)絡(luò)層實(shí)現(xiàn),涉及到MAC層接口的調(diào)用。本節(jié)先簡(jiǎn)單介紹本設(shè)計(jì)實(shí)驗(yàn)平臺(tái)上網(wǎng)絡(luò)模塊提供的MAC層應(yīng)用接口,然后詳細(xì)論述軟件的設(shè)計(jì)和實(shí)現(xiàn)。
3.3.1 MAC層接口簡(jiǎn)介
首先做兩點(diǎn)說明。
第一,設(shè)計(jì)中使用的MAC層接口不提供絕對(duì)可靠的網(wǎng)絡(luò)通信。一方面是因?yàn)樵O(shè)計(jì)使用實(shí)驗(yàn)室自制的硬件平臺(tái)主要用于做群體實(shí)驗(yàn),而群體實(shí)驗(yàn)不需要可靠的網(wǎng)絡(luò)通信,所以平臺(tái)的通信模塊也沒有能實(shí)現(xiàn)可靠通信的機(jī)制;另一方面要求MAC層提供可靠通信也不是必要的。
第二,網(wǎng)絡(luò)層只使用了MAC層提供的數(shù)據(jù)幀發(fā)送和數(shù)據(jù)幀接收兩個(gè)接口,網(wǎng)絡(luò)層的幀結(jié)構(gòu)包含在MAC數(shù)據(jù)幀的數(shù)據(jù)域中。
從第一點(diǎn)可以看到,協(xié)議在網(wǎng)絡(luò)層實(shí)現(xiàn)可靠數(shù)據(jù)傳輸?shù)臋C(jī)制,降低了對(duì)MAC層通信質(zhì)量的要求,而第二點(diǎn)說明協(xié)議僅僅需要MAC層提供兩個(gè)最基本的應(yīng)用接口。本設(shè)計(jì)中的可靠數(shù)據(jù)分發(fā)協(xié)議對(duì)底層通信的要求很低,具有較好的魯棒性和可移植性。
本設(shè)計(jì)實(shí)驗(yàn)平臺(tái)上提供的MAC層數(shù)據(jù)幀發(fā)送命令結(jié)構(gòu)如圖4.4所示,其中區(qū)域3為數(shù)據(jù)域,包含網(wǎng)絡(luò)層的幀結(jié)構(gòu),另外節(jié)點(diǎn)在MAC層以廣播的方式通信,所以命令中不包含源節(jié)點(diǎn)和目的節(jié)點(diǎn)的地址信息。MAC層接收到數(shù)據(jù)幀后,將數(shù)據(jù)域分離出來存儲(chǔ)到接收緩存區(qū);發(fā)送數(shù)據(jù)時(shí),將發(fā)送緩存區(qū)中的數(shù)據(jù)加上MAC層數(shù)據(jù)幀的頭部和尾部并發(fā)送出去,網(wǎng)絡(luò)層只關(guān)心發(fā)送和接收緩沖區(qū)中的數(shù)據(jù)。這里規(guī)定以下章節(jié)中提到的各種幀結(jié)構(gòu)均指網(wǎng)絡(luò)層幀結(jié)構(gòu)。
3.3.2 可靠數(shù)據(jù)分發(fā)協(xié)議的數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)
網(wǎng)絡(luò)層數(shù)據(jù)要經(jīng)過緩存,解析再到存儲(chǔ)或者執(zhí)行三步操作,并且不同種類的幀要區(qū)別處理,因此一個(gè)好的數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)方案對(duì)簡(jiǎn)化數(shù)據(jù)處理操作和提高數(shù)據(jù)處理效率是非常有必要的。圖4.5為網(wǎng)絡(luò)層數(shù)據(jù)流圖,數(shù)據(jù)幀的流向?yàn)椋?/p>
從MAC層讀入后放入原始數(shù)據(jù)緩沖區(qū);
經(jīng)解析后得到幀結(jié)構(gòu);
將幀結(jié)構(gòu)作相關(guān)處理后僅提取頁號(hào)(p)、幀號(hào)(id)和數(shù)據(jù)(data)放到寫flash緩沖區(qū);
寫flash。
注意以上是數(shù)據(jù)幀的流向,除數(shù)據(jù)幀以外的其他類型幀(如請(qǐng)求幀,結(jié)束幀等)只執(zhí)行第(1)、(2)步操作。下面著重論述圖中每個(gè)階段涉及到的數(shù)據(jù)結(jié)構(gòu)。[!--empirenews.page--]
緩沖區(qū)Deluge_buf
Deluge_buf是一個(gè)環(huán)形緩沖區(qū),用于緩存原始的網(wǎng)絡(luò)層數(shù)據(jù)。緩沖區(qū)實(shí)際上是由一個(gè)環(huán)形鏈表、兩個(gè)指針和一個(gè)整數(shù)組成。鏈表的每個(gè)節(jié)點(diǎn)用于存儲(chǔ)實(shí)際數(shù)據(jù),節(jié)點(diǎn)數(shù)目根據(jù)需要而定;一個(gè)tail指針和一個(gè)head指針,分別指鏈表的讀出點(diǎn)和寫入點(diǎn),執(zhí)行一次讀出或?qū)懭氩僮骱?,tail或head指針都向前移動(dòng)一次,整數(shù)的作用是統(tǒng)計(jì)當(dāng)前鏈表上可用節(jié)點(diǎn)的數(shù)目。Deluge_buf結(jié)構(gòu)體定義如下:
struct Deluge_buf {
struct data_entry queue_data[QUEUE_LENGTH]; // The data of current queue
uint8 recv_num;
uint8 queue_head;
uint8 queue_tail;
};
值得注意的是結(jié)構(gòu)體data_entry中Payload項(xiàng)的組成在不同類型的幀中是不同的,比如數(shù)據(jù)幀中Payload包括頁號(hào)p、幀號(hào)id和數(shù)據(jù)data以及數(shù)據(jù)長度data_len,而廣告幀中只包含p和id,因此解析方法要根據(jù)type值來區(qū)分。
幀結(jié)構(gòu)DelugeData
如圖五所示,DelugeData定義了幀類型(type)等六個(gè)數(shù)據(jù)項(xiàng),設(shè)計(jì)中根據(jù)不同的幀類型規(guī)定了各個(gè)數(shù)據(jù)項(xiàng)的含義,具體定義如表4.1所示,“—”表示該數(shù)據(jù)項(xiàng)在幀中沒有定義。
表4.1 DelugeData中數(shù)據(jù)項(xiàng)含義的定義
數(shù)據(jù)項(xiàng) 幀類型 |
type |
v |
p |
id |
data |
data_len |
數(shù)據(jù)幀 |
DATA |
版本號(hào) |
頁號(hào) |
幀號(hào) |
數(shù)據(jù) |
數(shù)據(jù)長度 |
結(jié)束幀 |
END |
版本號(hào) |
頁號(hào) |
幀號(hào) |
— |
— |
廣告幀 |
ADV |
版本號(hào) |
頁號(hào) |
源節(jié)點(diǎn)標(biāo)識(shí) |
— |
— |
請(qǐng)求幀 |
REQ |
版本號(hào) |
頁號(hào) |
目標(biāo)節(jié)點(diǎn)標(biāo)識(shí) |
— |
— |
命令幀 |
CMD |
命令參數(shù) |
— |
— |
— |
— |
3、緩沖區(qū)Flash_buf
因?yàn)閷慺lash操作比網(wǎng)絡(luò)傳輸慢得多,為了避免寫flash拖慢整個(gè)數(shù)據(jù)分發(fā)速度,建立緩沖區(qū)Flash_buf用于緩存準(zhǔn)備好的數(shù)據(jù)。Flash_buf也是一個(gè)環(huán)形緩沖區(qū),原理和Deluge_buf相同。緩沖區(qū)的節(jié)點(diǎn)包含p、id、data三個(gè)數(shù)據(jù)項(xiàng)和指針域next,其中data是要寫入flash的數(shù)據(jù),p和id用于計(jì)算待寫入的flash地址。
3.3.3 可靠數(shù)據(jù)分發(fā)協(xié)議的軟件架構(gòu)設(shè)計(jì)
可靠數(shù)據(jù)分發(fā)協(xié)議的軟件構(gòu)架設(shè)計(jì)包括發(fā)送端和接收端兩塊內(nèi)容。發(fā)送端軟件運(yùn)行在數(shù)據(jù)基站上,分為兩個(gè)階段,第一階段通知節(jié)點(diǎn)連續(xù)地發(fā)送整個(gè)文件,第二階段運(yùn)行狀態(tài)機(jī)參與到節(jié)點(diǎn)的交流中去;接收端軟件運(yùn)行在待燒錄節(jié)點(diǎn)上,第一個(gè)階段盡可能多的接收基站發(fā)送來的數(shù)據(jù),第二階參與節(jié)點(diǎn)間討論。因?yàn)榘l(fā)送端第一階段軟件比較簡(jiǎn)單,第二階段和接收端相同,所以這里只重點(diǎn)介紹接收端的軟件構(gòu)架設(shè)計(jì)。
第一階段:
程序完成初始化后進(jìn)入準(zhǔn)備接收狀態(tài),當(dāng)數(shù)據(jù)幀到來時(shí)將數(shù)據(jù)提取出來寫到flash相應(yīng)的地址(地址由頁號(hào)p和幀號(hào)id計(jì)算得到),并將該幀標(biāo)記為“完成幀”;若接收到結(jié)束幀,則記錄結(jié)束幀的頁號(hào)pmax和幀號(hào)idmax并進(jìn)入第二階段;若接收到其他類型幀則直接進(jìn)入第二階段。第一階段的軟件流程圖如圖4.6所示。
第二階段:
完成第一輪接收后,程序運(yùn)行ADV-REQ-DATA狀態(tài)機(jī),和其他節(jié)點(diǎn)交流,完善或幫助其他節(jié)點(diǎn)完善數(shù)據(jù)文件。狀態(tài)機(jī)分為MAINTAIN(維護(hù))、RX(請(qǐng)求)和TX(發(fā)送)三個(gè)狀態(tài),程序首先進(jìn)入MAINTAIN狀態(tài)。MAINTAIN狀態(tài)下,程序監(jiān)聽廣告幀和請(qǐng)求幀并在適當(dāng)時(shí)機(jī)發(fā)送廣告,根據(jù)協(xié)議規(guī)定,程序可能跳轉(zhuǎn)到RX狀態(tài)或TX狀態(tài)進(jìn)行數(shù)據(jù)幀請(qǐng)求和發(fā)送操作,操作完成后返回MAINTAIN狀態(tài)。程序中定義一個(gè)最長時(shí)間tmax,如果MAINTAIN狀態(tài)持續(xù)時(shí)間超過tmax,則認(rèn)為整個(gè)數(shù)據(jù)分發(fā)過程結(jié)束,程序檢查自己接收到的數(shù)據(jù)是否完備后退出。第二階段的軟件流程圖如圖4.7所示。
四 系統(tǒng)測(cè)試
本測(cè)試將用三個(gè)程序作為用例,以測(cè)試系統(tǒng)的可用性。三個(gè)程序分別為:
Led.bin實(shí)現(xiàn)簡(jiǎn)單的跑馬燈;
GoAhead.bin 三輛小車將一直向前方走,即使碰到障礙物也不停止;
RandomWalk.bin 三輛小車將進(jìn)行隨機(jī)行走,并且碰到障礙物后會(huì)進(jìn)行壁障,轉(zhuǎn)彎。
首先我們將批量更新跑馬燈的程序,然后我們來看GoAhead.bin,如圖5.1所示。完整的程序鏡像大小為3340Bytes
當(dāng)前在節(jié)點(diǎn)上已經(jīng)運(yùn)行了Led.bin,我們將使用Led.bin和GoAhead.bin進(jìn)行比較,生成patch.bin文件,即補(bǔ)丁文件。
我們看到,生成的patch.bin文件僅僅是原程序GoAhead.bin的1/3大小!圖5.3是patch.bin代表的命令(截取一部分)。
下面從GoAhead.bin 生成 RandomWalk.bin,RandomWalk.bin的大小如圖5.4所示:
圖5.5從生成的patch.bin文件的大小可以看到,其為RandomWalk的大約1/3。但有個(gè)值得注意的地方是,RandomWalk.bin比GoAhead.bin大了1000多個(gè)字節(jié)。添加的著1000多個(gè)字節(jié)是占patch.bin的主要內(nèi)容??梢姲l(fā)送patch.bin比較適合于修改部分變量或者函數(shù)的時(shí)候。如果是單純的增加功能,比較適合于發(fā)送完整的鏡像文件。
五 總結(jié)
測(cè)試結(jié)果表明,本設(shè)計(jì)實(shí)現(xiàn)了可靠性無線批量嵌入式節(jié)點(diǎn)程序更新,燒錄出錯(cuò)率低;更新效率高;不依賴操作系統(tǒng),具有很好的可移植性,項(xiàng)目總體上實(shí)現(xiàn)了設(shè)計(jì)的目標(biāo)。另一方面由于時(shí)間限制,系統(tǒng)仍然存在一些不足。以下是設(shè)計(jì)中幾點(diǎn)需要優(yōu)化的地方和相應(yīng)的改進(jìn)意見。
系統(tǒng)在Linux環(huán)境下進(jìn)行了開發(fā)和應(yīng)用,沒有開發(fā)Windows版本。項(xiàng)目組準(zhǔn)備在下一階段把系統(tǒng)移植到Windows平臺(tái)上。
尚未實(shí)現(xiàn)程序的動(dòng)態(tài)更新,即每次更新前都要將正在運(yùn)行的程序關(guān)掉,強(qiáng)制節(jié)點(diǎn)進(jìn)入準(zhǔn)備狀態(tài)??梢苑峙湟粋€(gè)專用線程用于程序更新,同時(shí)為了避免更新對(duì)正在運(yùn)行的程序造成影響,需要在更新過程中引入動(dòng)態(tài)鏈接技術(shù)