引言
隨著移動技術和互聯網技術的飛速發(fā)展,移動網絡將是下一代網絡發(fā)展的大趨勢。而移動網絡的重要子網之一無線傳感器網絡能夠大大擴展互聯網的觸角。由于無線傳感器網絡低功耗、低成本、分布式和資源有限等特點,使得開發(fā)無線傳感器網絡的相關協(xié)議成為無線傳感器網絡發(fā)展的關鍵技術因素之一。傳統(tǒng)的軟件開發(fā)方法顯然已經不適合無線傳感器協(xié)議的開發(fā),而近來興起的新的開發(fā)模式是基于構件化的軟件開發(fā)方法。
基于構件化的軟件開發(fā)(CBSD,comp onent-based software development)方法是一種可以提供軟件復用性的開發(fā)方法。構件是用于進行軟件開發(fā)、復用和軟件組裝的基本單元。在面向構件的技術里,一個應用軟件不是通過大量的代碼來描述,而是通過數量有限的構件來描述,如圖1(a)所示。與傳統(tǒng)的嵌入式軟件不同,構件化的嵌入式軟件是由一組軟件構件構成的,這些構件的一個或者幾個組合成一個完整的應用;而且新的應用也可以使用已有構件,從而提高軟件復用性。傳統(tǒng)模式下開發(fā)出來的嵌入式軟件提供的是專用服務,軟件與應用是一一對應的,如圖1(b)所示。整個過程中代碼量大,復雜度高,代碼重用性小,并且更新困難,不適應無線傳感器節(jié)點資源有限的要求。
TinyOS是一種基于構件化的無線傳感器網絡操作系統(tǒng),該系統(tǒng)本身就是一個構件庫。其開發(fā)語言nesC提供了對軟件構件技術的支持。通過靈活組裝各個固定功能的芯片級構件可以方便地搭建起不同硬件平臺級構件。因此在TinyOS系統(tǒng)下開發(fā)構件化的無線傳感器協(xié)議的方法已被廣泛使用。但是,目前由于開發(fā)者過度依靠現有的集成構件,導致開發(fā)出來協(xié)議性能并不理想。
圖1 構件化的嵌入式軟件與傳統(tǒng)嵌入式軟件
系統(tǒng)為了簡化開發(fā)者的開發(fā)難度,對各芯片的底層構件進行了構件化包裝。調用硬件底層構件所提供的最基本功能接口,來組合實現一些功能模塊,如配制芯片模塊、發(fā)送數據模塊、接收數據模塊等。系統(tǒng)對各芯片的硬件抽象層的集成化操作基本是一樣的,圖2是CC2420系統(tǒng)集成構件調用硬件抽象層構件的關系。
圖2 系統(tǒng)集成構件和硬件抽象層構件關系
由圖2 可以看出,系統(tǒng)集成構件起到一個橋梁作用,使開發(fā)者簡化了開發(fā)工作。但是,系統(tǒng)集成構件在調用硬件抽象構件實現自身功能的時候出現重復調用問題。并且構件CC2420SpiC在不同的層(系統(tǒng)集成層和硬件抽象層)都有使用,這本身使得系統(tǒng)集成層和物理抽象層關系變得模糊和復雜,加大開發(fā)者開發(fā)難度。
根據構件化系統(tǒng)編程可知,調用構件的接口需要實現提供接口構件中的event 事件。如果多個構件重復使用同一個構件的同一個接口,每個使用該接口的構件都需要將該接口中的event 事件執(zhí)行一次。系統(tǒng)集成構件同時調用相同的硬件抽象層構件中的接口命令時,完成命令的signal 事件會通知每個使用該接口的構件。這就導致了構件化系統(tǒng)下編程常見問題:扇出(fan-out)。系統(tǒng)為了解決這一問題不得不將構件性質改為generic 類型。而這會引入新的構件調用模式。所有這些使得系統(tǒng)集成構件對硬件抽象層構件的調用變得比實際要復雜,代碼的執(zhí)行效率大大降低。
對系統(tǒng)集成構件的研究發(fā)現,應用層構件在調用系統(tǒng)集成構件時最終調用了硬件抽象層構件,只是系統(tǒng)集成構件將硬件抽象層構件重新整合到某個大的集成構件中,方便用戶查找接口。實際上,由于嵌入式軟件和硬件結合性高、硬件資源有限等特點,為了使得軟件系統(tǒng)性能達到最高,嵌入式軟件開發(fā)者在開發(fā)之前對硬件已經非常熟悉。在這種情況下沒有必要在硬件抽象層之上硬性加上系統(tǒng)抽象層。對開發(fā)者而言,直接調用底層硬件抽象層構件會更直觀、簡單。
具體實現方法如圖3所示,在構件操作上對沒有引入新功能的構件在配線構件配線時候可以跨過整個系統(tǒng)集成構件,而不會影響系統(tǒng)功能,并可以簡化開發(fā)過程,提高運行效率。以下將這一方法簡稱為直接調用法。
圖3 構件簡化過程
圖3 中構件1 和構件2 不是提供最底層功能的構件,它們將底層構件3、構件4 和構件5 進行重新整合,最終使用的是構件3、構件4 和構件5 的功能。所以,通過改進后的方案中,讓應用構件直接調用構件3、構件4 和構件5,讓構件1 和構件2 的功能交給應用構件去完成,這樣提高了代碼的執(zhí)行效率和開發(fā)效率。實際上,結合構件化系統(tǒng)可知,圖3 的簡化過程解決了扇出問題,應用構件只要調用了一個硬件抽象層構件,就可以在應用構件內任何需要的地方去調用硬件抽象構件所提供的接口中命令。配線構件在配線時也變的簡單,沒有系統(tǒng)集成構件中多個硬件抽象層構件的重復配線操作。
圖4 改進方案中構件間關系
由圖4 可知,原來方案中的系統(tǒng)集成級構件層的構件沒有被調用,而直接調用硬件抽象層構件。由圖4 與圖2 對比發(fā)現,將原來系統(tǒng)集成層構件*能移到PhyP 構件中完成,這樣避免了對底層構件的重復使用,整個結構更清晰簡單。因此,需要對PhyP 構件做改進,使得其能夠完成初始化射頻芯片,調用射頻芯片發(fā)送和接受數據。雖然看起來PhyP 構件要比實際代碼量大,但是對改進后系統(tǒng)運行的測試結果表明,提高了10%的工作效率,縮減3000 行的代碼量。
3 測試直接調用法
將直接調用法應用IEEE802.15.4 的設計與實現。IEEE802.15.4 標準目前已成為事實上的無線傳感器標準,并在各自硬件平臺上開發(fā)該協(xié)議。以IEEE802.15.4 標準為例,在TinyOS系統(tǒng)、CC2420 射頻芯片的環(huán)境下使用本文直接調用法來設計實現該標準,并測試其工作性能。
3.1 功能測試
測試程序運行在兩個對等的節(jié)點上,分兩個階段測試。首先測試物理層的通信情況:一號個節(jié)點產生一個有效載荷為:0 至9十個數據的數據包并發(fā)送給另外二號節(jié)點,二號節(jié)點在收到上述數據包后原封不動將該數據包又發(fā)回給剛才發(fā)送者。發(fā)送和接收到的數據包的內容是一致的,并且信號燈閃爍正常,說明節(jié)點之間的通信正常,物理層設計工作正常。進一步測試MAC層工作情況:將一號節(jié)點設為協(xié)調器節(jié)點,二號節(jié)點設置為非協(xié)調器節(jié)點。一號節(jié)點初始化并建立一個PAN網,二號節(jié)點請求加入一號節(jié)點所創(chuàng)建的網中,驗證網絡是否工作正常。通過功能測試可知,整個工作過程是按照IEEE802.15.4 標準的規(guī)定運行,實現了該標準功能。
3.2 效率測試
工作效率測試中應用產生50 個數據包后調用MAC 層發(fā)送接口發(fā)送這50 個數據包,從應用調用MAC
層數據接口時開始計時,到應用層收到包成功發(fā)送的確認消息為止。記錄下這個響應時間,并依次增大發(fā)送數據包的的有效載荷,從10個字節(jié)增加到90,記錄下有效載和增加時的響應時間。效率測試將分別在原始方案和直接調用法開發(fā)出來的協(xié)議中進行,統(tǒng)計兩種不同方法的工作參數,最后得到的時間分布如圖5
所示。
由圖5 可知,在50 個數據包的情況下,當數據包的有效載荷在10 至50 個字節(jié)時二者響應時間差距并不大,響應時間提高了10%左右,當有效載荷增加到50個字節(jié)以上時,響應時間提高30%,有利于滿足嵌入式系統(tǒng)的實時性要求
結束語
本方案通過分析無線傳感器網絡現有的開發(fā)方法的不足,提出直接調用法,并用該方法實現IEEE802.15.4標準,最終達到預期目標。方案的移植性高,穩(wěn)定性好,代碼量小,適合無線傳感器資源有限,實時性要求高的特點。同時直接調用法可以用來開發(fā)其他通信協(xié)議,如:802.11、LEACH、藍牙等。