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