基于OMNeT++的“實代碼”仿真模式研究*

時間：2018-07-09 16:30:06

關(guān)鍵字：代碼模式 omnet

手機看文章

掃描二維碼
隨時隨地手機看文章

摘要: 嘗試搭建一個基于OMNeT++仿真器的“實代碼仿真模式”的研究，將整套UCOS系統(tǒng)上運行的協(xié)議代碼封裝成動態(tài)鏈接庫，加載到仿真器上利用其離散仿真事件隊列機制進行調(diào)試，運行通過后可以直接在實際硬件芯片上運行，無需二次修改，大大提高研究開發(fā)進度。成功地將UCOS上運行的aloha協(xié)議棧封裝成DLL加載到OMNeT++，調(diào)試運行通過并且已經(jīng)投入到實際應(yīng)用中。
關(guān)鍵詞: 無線傳感網(wǎng); OMNeT++; 實代碼仿真; 動態(tài)鏈接庫

1 OMNeT++
　無線傳感器網(wǎng)絡(luò)由稱為“微塵(mote)”的微型計算機構(gòu)成。這些微型計算機通常指帶有無線鏈路的微型獨立節(jié)能型計算機。無線鏈路使得各個微塵可以通過自我重組形成網(wǎng)絡(luò)，彼此通信并交換有關(guān)現(xiàn)實世界的信息。目前，對于傳感網(wǎng)的研究越來越受到關(guān)注，其中網(wǎng)絡(luò)協(xié)議算法更是其中的熱點之一。
　為評價傳感器網(wǎng)絡(luò)協(xié)議算法的性能，僅通過實驗是無法實現(xiàn)的，特別是包含大量節(jié)點的大規(guī)模無線傳感器網(wǎng)絡(luò)[1]，更是很難通過實驗來實現(xiàn)(實際上，上百個節(jié)點的實驗己經(jīng)比較難以管理與實現(xiàn))。為了實現(xiàn)無線傳感器網(wǎng)絡(luò)的仿真,研究人員設(shè)計開發(fā)了許多仿真平臺(或在現(xiàn)有平臺建立無線傳感器網(wǎng)絡(luò)模型),包括NS-2、OPNET、SensorSim、EmStar、OMNet++、GloMoSim、TOSSIM、PowerTOSSIM等。
OMNeT++[2-3](Objective Modular Network TestBed in C++)是開源的基于組件的模塊化的開放網(wǎng)絡(luò)仿真平臺，是近年來在科學(xué)和工業(yè)領(lǐng)域里逐漸流行的一種優(yōu)秀的網(wǎng)絡(luò)仿真平臺。OMNeT++作為離散事件仿真器，具備強大完善的圖形界面接口和可嵌入式仿真內(nèi)核，同NS2[4]、OPNET[5]和JavaSim等仿真平臺相比，OMNeT++可運行于多個操作系統(tǒng)平臺，可以簡便定義網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，具備編程、調(diào)試和跟蹤支持等功能。OMNeT++主要用于通信網(wǎng)絡(luò)和分布式系統(tǒng)的仿真。
OMNeT++具有模塊化的結(jié)構(gòu),圖1是OMNeT++仿真的高層體系結(jié)構(gòu)。

2 實代碼仿真
2.1 總體思路
　對于傳統(tǒng)的有線網(wǎng)絡(luò), 利用有限的具有代表性的節(jié)點拓?fù)渚涂梢韵喈?dāng)大程度地模擬整個網(wǎng)絡(luò)的性能, 但是對于無線傳感器網(wǎng)絡(luò), 由于其大冗余度和高密度節(jié)點拓?fù)錁?gòu)造類型而無法用有限的節(jié)點數(shù)目來分析其整體性能。因此在仿真規(guī)模上必須考慮大量節(jié)點的并行運算,WSN 節(jié)點有可能成千上萬甚至更多。
仿真可以在算法和實現(xiàn)之間起到橋梁作用, 從仿真到實現(xiàn)不要進行二次編碼, 而是平滑過渡。經(jīng)過仿真測試和驗證了的代碼能夠直接在硬件上運行, 但經(jīng)常出現(xiàn)算法仿真通過而實際卻不能實現(xiàn)的情況。
本論文研究實代碼仿真的主要原理就是將硬件中斷換成離散仿真事件，由仿真器事件拋出的中斷來驅(qū)動上層應(yīng)用，也即節(jié)點實代碼。
總體思路框架圖如圖2所示，不同節(jié)點類型、不同數(shù)目的同一類型節(jié)點都可以在支持分布式仿真的仿真模擬器OMNET++上運行，仿真的具體思路就是將每一個節(jié)點(對應(yīng)一個對象)抽象成一個線程(線程始終運行)，其次將需要仿真的實代碼以動態(tài)鏈接庫的形式調(diào)入線程中，由OMNeT++底層的離散仿真事件驅(qū)動編譯成DLL的代碼。

本次試驗的DLL動態(tài)鏈接庫為ucos系統(tǒng)上的系統(tǒng)軟件協(xié)議棧。其中附加運行的任務(wù)為測試程序，實際應(yīng)用過程中存放的是在硬件上運行的OS的節(jié)點代碼。
2.2 動態(tài)鏈接庫
動態(tài)鏈接庫簡稱DLL ,它是基于Windows 程序設(shè)計的一個非常重要的組成部分，可以被其他應(yīng)用程序所共享的程序模塊，其中封裝了一些可以被共享的里程和資源[6]。與使用普通的函數(shù)庫相比,它并不是將庫中的代碼拷貝到可執(zhí)行文件中,而是在建立應(yīng)用程序的可執(zhí)行文件時動態(tài)裝載到動態(tài)鏈接庫DLL[7-8] ,裝載時DLL被映射到進程的地址空間中,在程序中記錄函數(shù)的入口點和接口,不管多少程序使用DLL ,內(nèi)存中都只有一個DLL副本,當(dāng)沒有程序使用時,系統(tǒng)將其移出內(nèi)存,減少了對內(nèi)存和磁盤的要求。
　本文簡單地編譯了一個DLL,將運行在UCOS上的Aloha協(xié)議封裝成DLL，協(xié)議功能就在于實現(xiàn)簡單的偵聽功能。為了進行驗證，在stack中附加輸出test()函數(shù)，函數(shù)功能就是將全局變量m自增1，返回m值。
int m=0;
int test()
{
m++;
return m;
}
然后通過.def文件將OS啟動入口函數(shù)test（)導(dǎo)出如下：
LIBRARY dlltest
EXPORTS
test
　這樣在vc6.0++環(huán)境目錄中,可以得到dlltest.dll文件，將其拷貝到omnetpp-4.0samplestest下即可以在OMNeT++中的源文件中調(diào)用，具體調(diào)用方式為GetProcAddress（)顯式調(diào)用。
2.3 節(jié)點切換：PE文件解析
　將代碼以動態(tài)鏈接庫的方式加載入內(nèi)存后，每個節(jié)點將會加載該DLL，這樣將會出現(xiàn)DLL中的全局變量等信息無限次地被每個節(jié)點所更改。其結(jié)果將是第二個節(jié)點的全局變量信息也許會成為第一個節(jié)點的全局變量信息。
　但是，所希望得到的結(jié)果是第一個節(jié)點的全局變量信息始終是第一個節(jié)點的，第二個節(jié)點的全局信息也始終是第二個節(jié)點的。這樣，自然而然想到的就是如何保護全局變量的問題。本工程所采用的一個小技巧就是每個節(jié)點產(chǎn)生一個數(shù)組，來保存節(jié)點信息。在這里要重點區(qū)別于多進程共享全局變量問題，本文涉及到的內(nèi)容主要為線程間共享數(shù)據(jù)。
DLL為PE文件結(jié)構(gòu)如圖3所示。

PE[9]文件格式是Win32平臺上(包括 Windows9x/NT/2000/XP/2003/Vista/CE)主流的可執(zhí)行文件格式，是Portable Executable File Format(可移植的執(zhí)行體)簡寫。它衍生于早期建立在VAX/VMS上的COFF(Common Object File Format)文件格式。對PE格式和COFF文件的主要描述存放在winnt.h文件中，它是PE文件定義的最終決定者。
　文件偏移地址是指當(dāng)PE文件存貯在磁盤上時，某個數(shù)據(jù)的位置相對于頭文件的偏移量，稱為文件偏移地址(File Offset)或物理地址(RAW Offset)。文件偏移地址從PE文件的第一個字節(jié)開始計數(shù)，起始值為0。
　相對虛擬地址(RVA)只是內(nèi)存中的一個簡單的相對于PE文件裝入地址的偏移位置，它是一個“相對”地址，或稱“偏移量”。圖2顯示了PE文件在裝入前后的相對位置變化。虛擬地址(VA)=基地址(ImageBase)+ 相對虛擬地址(RVA)。
　本文所編動態(tài)鏈接庫(DLL)函數(shù)中的全局變量是儲存在.data段中的。這樣就牽扯到每個節(jié)點運行后，要將其.data段的信息保存在數(shù)組中，在下次這個節(jié)點運行時再將其拷貝回.data段中，保證加載在內(nèi)存中的DLL不被其他的節(jié)點所更改。
其中重要部分是找到動態(tài)鏈接庫在內(nèi)存中的位置地址，然后根據(jù)PE文件結(jié)構(gòu)來解析data段的位置，以及其data段的大小。
　偽代碼如下：
　　const char *szSecName=".data";
　　hInst=LoadLibrary();
　　……
　　IMAGE_DOS_HEADER *pDosHead;
　　IMAGE_FILE_HEADER *pPEHead;
　　IMAGE_SECTION_HEADER *pSection;
　　……
　　strncmp(szSecName, (const char*)pSection[i].Name, IMAGE_SIZEOF_SHORT_NAME)；
　　 ……
在每個節(jié)點的node::initialize()中，為每個節(jié)點建立一個線程，而此線程就是將文中提到的“實代碼”以顯式鏈接的方式加載到其中。需要注意的是，這個線程是一直運行的，線程間以信號量的形式進行通信。也即在主線程中設(shè)置信號量為：
　　……
　　 SetEvent(eventM);
　　 ……
　　 WaitForSingleObject(eventT, INFINITE);
　　 ……
　　當(dāng)然，在各個線程中：
　　 ……
　　 WaitForSingleObject(eventM, INFINITE);
　　 ……
　　 SetEvent(eventT);
　　 ……
通過這種方式來進行線程間的交互，達(dá)到主線程(Omnet++)模擬的硬件中斷驅(qū)動上層的目的。其中多個線程中的主線程用來仿真所有節(jié)點應(yīng)用的運行，而分線程主要用來向外部動態(tài)鏈接庫程序提供服務(wù)和接受外部程序發(fā)送過來的命令。
　實際消息處理過程中數(shù)組中,將保存的信息段數(shù)據(jù)復(fù)制到PE文件中的全局?jǐn)?shù)據(jù)段地址就是在SetEvent(eventM)消息處理之前進行的，而WaitForSingleObject(eventT, INFINITE)之后再將運行完成后的數(shù)據(jù)段拷貝回數(shù)組中。
2.4 OMNeT++配置
(1) Ned文件的編寫
　 NED語言用來刻畫定義模型的拓?fù)浣Y(jié)構(gòu)，方便對一個網(wǎng)絡(luò)的模型化描述，這意味著一個網(wǎng)絡(luò)的描述可以包括一組元件的描述(通道，簡單/復(fù)雜模型)，這些組件的描述可以在其他網(wǎng)絡(luò)描述中得以重用。包含網(wǎng)絡(luò)描述的文件帶有.Ned的后綴，.Ned文件動態(tài)地載入到模擬程序，或者用Ned編譯器或C++代碼鏈接到模擬器執(zhí)行。NED文件可以使用任何文本編輯器或GNED圖形編輯器來編寫。
　本次試驗中設(shè)定了兩種不同類型的節(jié)點：普通節(jié)點和匯聚節(jié)點。每種類型的節(jié)點為一個簡單模塊。而普通節(jié)點的數(shù)目作為一個可變參數(shù)由輸入者自己確定。
　模塊聲明只定義了模塊類型，要確實地獲得一個仿真器能運行的模塊，需要書寫網(wǎng)絡(luò)定義。網(wǎng)絡(luò)定義將前面定義的模塊類型聲明為一個仿真模塊實例，盡管可以將一個模塊作為自包含的簡單模塊并實例為一個網(wǎng)絡(luò)，但應(yīng)用中更希望使用復(fù)合模塊類型。在NED文件中可以有幾個網(wǎng)絡(luò)定義仿真程序，使用NED文件可運行其中任何一個，可以在配置文件時選擇最想使用的那個，本次試驗的網(wǎng)絡(luò)定義語法如下：
network net
　　 {
　　 parameters:
　　 @display("bgi=background/terrain");
　　 int numNodes;
　　 submodules:
　　 node[numNodes]: node {
　　 parameters:
　　 @display("i=,cyan");
　　 }
　　 s_node: s_node {
　　 parameters:
　　 @display("i=,gold");
　 }
　其中用圖形化編輯如圖4所示。

　(2) node.cc文件編寫
　正如前文所述，每個節(jié)點抽象為一個線程，node::initialize()中，為每個節(jié)點建立一個線程，該線程是一直運行的。同時，對于PE文件結(jié)構(gòu)的解析也在此函數(shù)中完成。node::handlemessage()中，模擬中斷的產(chǎn)生，通過自發(fā)信息延遲一定時間來實現(xiàn)模擬定時中斷，然后置信號量來實現(xiàn)。
　s_node.cc文件的編寫類似node.cc文件。
　(3) 信道配置
離散事件系統(tǒng)是指一個系統(tǒng)的狀態(tài)改變是離散的，在兩個連續(xù)事件之間沒有任何事件發(fā)生。簡單地說，事件規(guī)定了系統(tǒng)狀態(tài)的改變，狀態(tài)的修改僅在事件發(fā)生時進行。離散事件系統(tǒng)可以使用離散事件模擬仿真。例如，計算機網(wǎng)絡(luò)通常被看作是離散事件系統(tǒng)。部分事件包括包傳輸?shù)拈_始、包傳輸?shù)慕Y(jié)束、重傳等待時間到達(dá)。
3 結(jié)果討論
按照上述基本步驟的編寫結(jié)果布局如下，普通節(jié)點數(shù)目設(shè)置為20。
分析以上結(jié)果可以看到：圖5所示為初始布局，配置文件中設(shè)置的普通節(jié)點數(shù)目為20，匯聚節(jié)點數(shù)目為1。圖6清晰地顯示了動態(tài)鏈接庫在進程中的內(nèi)存加載位置，并且由其PE文件結(jié)構(gòu)可以得知其各個段的分布情況：起始位置、長度等。data數(shù)據(jù)段的地址以及長度就可以順利得到。當(dāng)不采用數(shù)組時每個節(jié)點是順序增加的，如圖7所示。這說明每個節(jié)點的全局變量信息都是上一個節(jié)點的全局變量信息，全局變量依次遞增。相反，采用數(shù)組進行保存后，其中的各個節(jié)點全局信息將自己進行保存，如圖8所示。即達(dá)到本文試驗研究的初步預(yù)期結(jié)果：將實代碼以DLL形式加載到進程后，多節(jié)點抽象出的多線程將會共享DLL，表示節(jié)點狀態(tài)的全局變量將會被不同節(jié)點修改，此工程設(shè)計的PE文件數(shù)據(jù)段的拷貝很好地解決了這個問題。

基于OMNeT++的“實代碼”仿真具有很強的可伸縮性。對于無線傳感器網(wǎng)絡(luò), 由于其大冗余度、高密度節(jié)點拓?fù)錁?gòu)造類型, 所以無法用少量的節(jié)點數(shù)目來分析其整體性能。因此在仿真規(guī)模上必須考慮大量節(jié)點的并行運算,WSN 節(jié)點有可能成千上萬甚至更多；同時仿真應(yīng)能夠在算法和實現(xiàn)之間起到橋梁作用, 從仿真到實現(xiàn)不要進行二次編碼, 而是平滑過渡。仿真時測試和驗證了的代碼能夠直接在硬件上運行, 因為經(jīng)常出現(xiàn)算法仿真通過而實際卻不能實現(xiàn)的情況。
本項目的主要貢獻(xiàn)就在于提出了一種全新的驗證協(xié)議代碼的方案。它實現(xiàn)了在OMNeT++這款離散仿真軟件的基礎(chǔ)上，對運行在UCOS上的協(xié)議棧代碼直接仿真調(diào)試,將其封裝成為動態(tài)鏈接庫的形式在OMNeT++上調(diào)試運行，協(xié)議棧等代碼無需二次修改，運行后的代碼可以直接在節(jié)點上運行。具體思路已經(jīng)如上驗證通過，并且已經(jīng)將Aloha簡單的協(xié)議運行在芯片上，更深入的研究正在進行中。
參考文獻(xiàn)
[1] AKYILDIZ I F,SU W, SANKARASUBRAMANIAM Y,et al. Wireless sensor networks: a survey[J]. Computer Networks,2002,38:393-422.
[2] OMNeT++ Home Page. http://www.omnetpp.org, 2007(9).
[3] VARGA A. 2001. The OMNeT++ discrete event simulation system. In the proceedings of the european simulation Multiconference(ESM 6-9, 2001(6). Prague, Czech Republic).
[4] BAJAJ S, BRESLAU L, ESTRIN D. Improving simulation for network research. IEEE Computer. to appear, a preliminary draft is currently available as USC technical report 2000:99-702.
[5] OPNET Technologies, Inc. OPNET Modeler. http://www.opnet.com, 2007(9).
[6] KRUGLINSKI D L. Visual C++技術(shù)內(nèi)幕[M]. 潘愛民，王國印,譯.北京：清華大學(xué)出版社，2000.
[7] 費佩燕. VC++中動態(tài)鏈接庫的實現(xiàn)[J]. 現(xiàn)代電子技術(shù), 2003,28(8):7-18.
[8] 李海霞. VC中的動態(tài)鏈接庫應(yīng)用[M]. 軟件應(yīng)用,2004. [9] MATT PIETREK.Windows95 系統(tǒng)程式設(shè)計大奧秘[M].臺灣:旗標(biāo)出版有限公司,1997.