無線傳感網絡的構件化軟件開發

　　圖3 中構件1 和構件2 不是提供最底層功能的構件，它們將底層構件3、構件4 和構件5 進行重新整合，最終使用的是構件3、構件4 和構件5 的功能。所以，通過改進后的方案中，讓應用構件直接調用構件3、構件4 和構件5，讓構件1 和構件2 的功能交給應用構件去完成，這樣提高了代碼的執行效率和開發效率。實際上，結合構件化系統可知，圖3 的簡化過程解決了扇出問題，應用構件只要調用了一個硬件抽象層構件，就可以在應用構件內任何需要的地方去調用硬件抽象構件所提供的接口中命令。配線構件在配線時也變的簡單，沒有系統集成構件中多個硬件抽象層構件的重復配線操作。

　　對構件化系統以及底層硬件抽象構件和各具體芯片研究分析可知，系統集成構件都是起到上述作用，同時又引入新的問題。若開發人員對硬件抽象構件熟悉，就完全可以跨過系統集成構件而直接使用硬件抽象層提供的構件。這樣就簡化了原方案中系統集成構件之間繁雜的調用關系，更重要的是可以大大提高系統的運行效率，還以CC2420 系統集成構件為例，其改進后的構件調用方案如圖4 所示：

圖4 改進方案中構件間關系

　　由圖4 可知，原來方案中的系統集成級構件層的構件沒有被調用，而直接調用硬件抽象層構件。由圖4 與圖2 對比發現，將原來系統集成層構件*能移到PhyP 構件中完成，這樣避免了對底層構件的重復使用，整個結構更清晰簡單。因此，需要對PhyP 構件做改進，使得其能夠完成初始化射頻芯片，調用射頻芯片發送和接受數據。雖然看起來PhyP 構件要比實際代碼量大，但是對改進后系統運行的測試結果表明，提高了10%的工作效率，縮減3000 行的代碼量。

3 測試直接調用法

　　將直接調用法應用IEEE802.15.4 的設計與實現。IEEE802.15.4 標準目前已成為事實上的無線傳感器標準，并在各自硬件平臺上開發該協議。以IEEE802.15.4 標準為例，在TinyOS系統、CC2420 射頻芯片的環境下使用本文直接調用法來設計實現該標準，并測試其工作性能。

　　設計按照TinyOS 系統的構件化編程思路進行。物理層將設計兩個構件(PhyP，PhyC)，相關操作通過標準中定義的兩個接口進行：數據訪問接口(PD)、管理接口(PLME)。構件PhyP 是物理層的主要實現構件，它具有初始化構件、發送數據、接受數據三個基本功能。MAC 層設計兩個構件：MacC、MacP，其中MacP 是主要的執行構件。MAC 層中有兩種設備：協調器節點和非協調器節點。協調器節點負責建立網絡：確立網絡號(PANID)、本節點的短地址、并產生信標幀載荷部分。非協調器節點加入協調器節點所建立的網絡中組成更大的個人區域網絡。

　　3.1 功能測試

　　測試程序運行在兩個對等的節點上，分兩個階段測試。首先測試物理層的通信情況：一號個節點產生一個有效載荷為：0 至9 十個數據的數據包并發送給另外二號節點，二號節點在收到上述數據包后原封不動將該數據包又發回給剛才發送者。發送和接收到的數據包的內容是一致的，并且信號燈閃爍正常，說明節點之間的通信正常，物理層設計工作正常。進一步測試MAC 層工作情況：將一號節點設為協調器節點，二號節點設置為非協調器節點。一號節點初始化并建立一個PAN 網，二號節點請求加入一號節點所創建的網中，驗證網絡是否工作正常。通過功能測試可知，整個工作過程是按照IEEE802.15.4 標準的規定運行，實現了該標準功能。

　　3.2 效率測試

　　工作效率測試中應用產生50 個數據包后調用MAC 層發送接口發送這50 個數據包，從應用調用MAC 層數據接口時開始計時，到應用層收到包成功發送的確認消息為止。記錄下這個響應時間，并依次增大發送數據包的的有效載荷，從10 個字節增加到90，記錄下有效載和增加時的響應時間。效率測試將分別在原始方案和直接調用法開發出來的協議中進行，統計兩種不同方法的工作參數，最后得到的時間分布如圖5 所示。

圖5 收發數據效率比較

　　由圖5 可知，在50 個數據包的情況下，當數據包的有效載荷在10 至50 個字節時二者響應時間差距并不大，響應時間提高了10%左右，當有效載荷增加到50 個字節以上時，響應時間提高30%，有利于滿足嵌入式系統的實時性要求

　　結束語

　　本方案通過分析無線傳感器網絡現有的開發方法的不足，提出直接調用法，并用該方法實現IEEE802.15.4 標準，最終達到預期目標。方案的移植性高，穩定性好，代碼量小，適合無線傳感器資源有限，實時性要求高的特點。同時直接調用法可以用來開發其他通信協議，如：802.11、LEACH、藍牙等。