2 概述

2.1 模型基本觀念 (Modeling Concepts)

OMNeT ++模型是由modules所組成，module間藉由message物件的交換來達到通訊的目的。最底層的活動模組稱為Simple module，是使用模擬類別資料庫以及C++語言撰寫而成。數個Simple module可以組合成複合式模組(compound modules)，複合式模組還可以互相組合，沒有限制。整個OMNeT++模型，稱為Network本身即為一個compound module。訊息(message)可以藉由連線(connection)傳遞或是直接傳給modules。簡單模組和複合式模組的觀念類似於DEVS atomic和coupled models。

下圖中，灰色的方塊表示簡單模組，透明的大方塊表示複合式模組。有箭號的線段連接小的方塊分別表示為連線(connection)和閘(gate)。

over-modules
(圖：簡單與複合式模組)

模組(module)間的通訊使用訊息(message)來完成，而訊息可以是包含任意的資料型別。Simple Module通常藉由gate傳送message，不過也可以直接傳送message給它的目的端。Gate是一種輸入與輸出的介面模組，message 藉由輸出的gate送出，而藉由輸入gate接收。輸出gate和輸入gate之間可以透過connection來連接(註*2-1)。 Connections只能被建立在單一個模組階層中，在一個複合式模組當中，兩個子模組相對應的的gates (輸出與輸入)，或是一個子模組的gate和 另一個複合式模組的gate可以透過connection相互連接。Connection跨越模組階層連接兩個gate是不被允許的，因為那會妨礙到 模組重複使用的功能。因為階層式模型架構的關係，message典型的透過一連串的connection來傳遞，從simple module開始，傳送到另一個simple module。複合式模組(Compound modules)在模型內的動作就像是一個硬紙箱，透明的在它的內部元件和外部的世界間傳遞訊息。傳送的參數，例如傳輸延遲、資料速率、以及位元錯誤率 (bit error rate)都可以被設定在connection中。我們也可以自己定義連線的型別以及賦予它特別的屬性並在不同的模擬中重複的使用它，這些自定義的連線被 賦予另外一個名稱叫做channel。Module也可以有參數，這些參數主要是被用來傳遞組態設定值給simple module以及幫助定義模型的拓樸。參數可以是字串、數值、或是布林值。因為參數是以一個物件的方式在模擬程式中存在，所以它除了用常數的方式存在以 外，還可以設計成為一個可以隨著模型組態而改變的隨機變數。它們可以使用人機介面讓使用者設定其數值，也可以是其他模擬參數的計算結果。複合式模組可以傳 遞參數給它們的子模組，也可以傳遞參數所形成的公式給它們的子模組。

(譯註*2-1：讀者可能會納悶為何在翻譯的時候要保留英文名詞，這是因為這些名詞在OMNeT++中都是定義好的類別，如果你有良好的物件導向程式訓練基礎那麼在閱讀文件的過程中大概有可以對於OMNeT++各類別的定義與使用有清楚的概念)

OMNeT++ 提供有效率的工具來幫助使用者描述實際系統的結構。一些主要的工具特性如下：

  • 階層式巢狀模組
  • 模組為模組型別的實例 (註*2-2)
  • 模組(module)間藉由通道(channel)來交換訊息(message)以達成互相通訊的目的
  • 有彈性的模組參數
  • 拓樸描述語言

(譯註*2-2：are instances of 是物件導向程式設計中的術語，意思是module type為一個類別，module是依照此類別所建立的物件)

2.1.1 階層式模組架構 (Hierarchical Modules)

一 個OMNeT++的模型是由階層式巢狀模組所組成，模組藉由訊息互相通訊。OMNeT++模型通常被稱為”網路” (Network)。在高層級的模組是系統模組(system module)。系統模組包含子模組，這些子模組也包含它們自己的子模組。模組階層的深度是沒有限制的，這讓使用者可以將實際系統的行為真實的反應到模擬 程式當中。

模型結構在OMNeT++中是使用NED語言來撰寫定義。

包含子模組的模組稱為複合式模組(compound module)，沒有包含子模組的模組稱為簡單模組(simple module)，簡單模組為模組階層中最底層的元件。簡單模組包含了模型的演算法，使用者使用C++語言以及OMNeT++所包含的模擬類別資料庫來撰寫簡單模組。

2.1.2 模組型別 (Module Types)

簡單模組和複合式模組都是屬於模組型別(module types)的實例(instance)。在模型建立過程中，使用者定義模組型別，建立這些模組型別的實例作為其他更複雜模組型別的元件。最終，使用者可以實現(instantiate，註*2-3))這些預先定義好的模組型別建立出系統模組。在一個網路下面的所有的模組都是其子模組與他們的子-子模組所組成。

(譯註*2-3: 讀者需要有一點物件導向的觀念。簡單講，模組型別是類別；模組為物件，藉由類別的繼承衍生以及組合可以形成一個複雜的系統模型)

當一個模組型別被使用當作一個結構方塊，系統並不會在乎它是一個間單模組還是一個複合型模組。這允許使用者將一個簡單模組再細分為幾個簡單模組嵌入至一個複合式模組；或者相反，集成一個複合式模組的功能成為一個簡單模組而不需要影響到現有模組型別的使用。

模組型別可以被儲存在其他的檔案裡，而不需要和模擬專案放在一起。這表示使用者可以將現有的模組型別收集統整去建立一個元件函式庫(component libraries)，這項功能將在第十章裡討論。

2.1.3 訊息、閘、與連線 (Messages, Gates, Links)

模組間的通訊是藉由訊息(message)所完成。在實際的模擬系統中，訊息表示在電腦網路裡面封包訊框封裝的內容、在排隊網路裡面表示工作或顧客、或是其他型別的行動單元。訊息可以包含任意且複雜型別的資料結構。簡單模組能夠直接傳送或是藉由預先定義好的路徑(透過閘和連線)傳送訊息給它的目的端。

“本地模擬時間” (“local simulation time”)會在模組接收到訊息的時候調整(前進)(註*2-4)。此訊息可以是來自於其他模組或是由本身所產生的訊息(本身所產生的訊息被用來實現計時器)

(譯 註*2-4：OMNeT++是一個離散時間事件模擬系統，時間的進行是依照事件發生的前後順序而觸發。一個模組接收到訊息，表示一個事件觸發，模組會更新內部的時鐘並檢查上一次更新時鐘到這一次更新時鐘間該模組應該要做哪些事情(產生事件)，然後將所產生的事件訊息放進模擬程式的訊息佇列中。模擬核心的工作就是從訊息佇列中取出事件，然後將事件交給相符的模組來處理)

閘(Gate)是輸入與輸出介面模組。訊息使用輸出閘送出，由輸入閘到達。

每一個連線(connection, also called link)只能建立在模組階層的同一層中。在一個複合式模組中，兩個子模組相對應的的gates (輸出與輸入)，或是一個子模組的gate和 另一個複合式模組的gate可以透過connection相互連接，如下圖(譯註：原文網頁沒有圖，可以參考上面的圖)。

因為階層式模型架構的關係，訊息典型的透過一連串的連結來傳遞，從simple module開始，傳送到另一個simple module。複合式模組(Compound modules)在模型內的動作就像是一個硬紙箱，透明的在它的內部元件和外部的世界間傳遞訊息。

2.1.4 封包傳遞的模擬

對於通訊網路模擬，connection(連線)可以用來模擬實體線路(physical links)。connection提供下列參數：data rate, propagation delay, bit error rate，以及packet error rate。這些參數可以啟用或是可以停用，同時這些參數以及它們所使用的演算法都被封裝在channel(通道)物件中。使用者可以透過OMNeT++所提供的通道型別來模擬封包的傳遞，同時也可以自行建立新的通道型別。

2.1.5 參數設定

模組可以有相關的參數(parameters)，參數可以在NED檔案中設定或是在omnetpp.ini檔案中設定。

參數可以用來規範簡單模組的行為以及規劃模型的拓樸(topology)

參數可以使用字串、數值、或是布林變數，也可以使用XML資料樹來指定。數值參數包含其他參數的運算結果、呼叫C語言函數、機率分佈回傳值、或是使用者互動輸入值。

數值參數可以被用來以一個有彈性的方式來建構模型拓樸。在複合式模組中參數可以被用來定義有多少個子模組、有多少個gates、以及內部連結的方式。

2.1.6 拓樸描述法 (Topology Description Method)

使用者利用NED語言定義模型的結構。NED語言將在第三章詳細討論

2.2 演算法編程 (Programming the Algorithms)

模型中的簡單模組包含使用C語言撰寫的演算法，C語言是OMNeT++所支援的程式語言，可以使用OMNeT++所提供的強大資料庫函式。模擬程式的撰寫風格可以使用事件導向程序(event-driven)方式，或是使用程序導向(process-style)方式，同時物件導向的設計概念(繼承與多型等等)可以很容易的被用來擴展模擬器的功能。

使用的模擬物件(訊息、模組、佇列等)都是使用C++類別所表示。他們被設計成為適合有效率的共同工作，建立強大的模擬程式基礎架構。下面所列的類別資料庫為整個OMNeT++模擬類別資料庫中的一部分：

  • 模組、閘、參數、通道 (module, gate, parameter, channel)
  • 訊息、封包 (message, packet)
  • 容器類別(例如：佇列、陣列)
  • 資料收集類別
  • 統計以及機率分布估測類別 (historgrams, 動態計量所使用的P2 演算法等)
  • 暫態偵測與結果準確度偵測類別

這些類別均經過特別的設計，使得他們可以穿行過正在執行模擬的物件、顯示他們的資訊，諸如名稱、類別名稱、狀態變數數值或內容。這個特性使得OMNeT++能夠建立模擬程式GUI使得模擬的內部物件的狀態也可以很容易地被觀察到

2.3 使用OMNeT++ (Using OMNeT++)

2.3.1 建立與執行模擬 (Building and Running Simulations)

這節討論實際上使用OMNeT++時所需要了解的內容，像是模型檔案，編譯與執行模擬等

一個OMNeT++模型包含下面幾個部分：

  • NED語言拓樸描述檔案(.ned)，用來描述模型結構與參數、閘等等。NED檔案可以使用任何文字編輯器來編輯，但是OMNeT++的IDE本身就包含了一個強大的圖形與文字編輯環境
  • 訊息定義檔(.msg)，用來定義各種不同的訊息型別與增加資料欄位到訊息中。OMNeT++將會將此訊息定義轉換成為合格的C++類別
  • 簡單模組程式碼，為使用C++語言所撰寫的檔案，附檔名為.h, .cc等

模擬系統包含下面幾個項目：

  • 模擬核心(Simulation kernel)。管理模擬執行與模擬類別函式庫的程式碼，由C++寫成並編譯成分享式或是靜態函式庫(shared or static library)
  • 使用者介面(user interfaces)。OMNeT++使用者介面被使用在模擬執行、除錯、展示，或是批次模擬執行等，由C++寫成並編譯成為函式庫

模擬程式由上述元件所組成。首先，.msg檔被opp_msgc程式轉換成為C++程式碼，然後所有的C++來源碼被重新的編譯與連結，過程中會將simulation kernel和user interface函式庫包含進來形成一個可執行程式的或是一個分享式函式庫。NDE檔案則是在模擬程式開始執行的時候以原本的檔案形式被動態的載入到模擬程式中。

執行模擬與分析結果

模擬程式可以被編譯成為一個獨立可執行的程式，因此他可以在沒有安裝OMNeT++的機器上面執行或是它可以被建立成為一個分享式的函式庫。當作成分享式函式庫的時候，必須與OMNeT++共同存在。當程式開始執行，首先會讀取所有的NED檔案以載入模型拓樸，然後他讀取組態檔(通常稱為 omnetpp.ini)，這個檔案包含這個模型如何被執行的控制設定、模型參數的數值等等。組態檔同時可以指定多組設定讓模擬程式執行多次但使用不同的參數設定的模擬。在最簡單的情況，這多組模擬將會一個接著一個的分次連續執行。

模擬結果的輸出被寫入下列結果檔案：輸出向量檔(output vector files)、輸出純量檔(out scalar files)，或者是使用者自訂的輸出檔。OMNeT+具備一個整合開發環境(IDE)提供豐富的工具來分析這些結果輸出檔案。輸出的檔案是依照線性導向的文字檔案(line-oriented text files)(註*2-5)，因此可以容易地被各種不同類型的工具或程式語言處理，像是Matlab、GNU R、Perl、Python、以及試算表程式(註*2-6)。

(譯 註*2-5：以行為單位紀錄)

(譯 註*2-6：例如：Microsoft excel)

使用者介面

使用者介面的主要目的是讓模型的內部狀態可以被使用者觀察，可以去控制模擬的執行，可以有機會去修改變數/物件以改變模型的行為。這些都是在模擬專案開發與除厝階段非常重要的功能。同樣重要的，親自動手操作將讓使用者能夠更快的感受到模型的行為模式。圖形使用者介面同時被使用來展示模型的運行。

同一個模擬模型可以被不同的使用者介面來執行而不需要做任何的修改。使用者通常會使用圖形使用者介面來幫助模擬的測試與除錯，而最終運行模擬時會使用簡易且快速同時支援批次執行的使用者介面。

元件函式庫 (Component Libraries)

模組型別被儲存在不同的檔案目錄中，這讓使用者可以將現有的模組型別分門別類建立元件函式庫。

獨立的模擬程式

獨立可執行的模擬程式可以儲存數個使用同一組簡單模組的獨立的模型，使用者可以使用組態檔指定哪一個模型將要被執行。這允許我們去建立一個大的可執行檔，其中包含數個模擬模型並將此可執行檔視為一個獨立的模擬工具。OMNeT++中的拓樸描述語言同樣也支援這項特性。

2.3.2 OMNeT++ 4.6版內容

如果你安裝的是具有原始碼的版本，則在OMNeT++的目錄下將會包含下列子目錄(如果你安裝的是預先編輯的版本，有一些子目錄將不會存在，或是多出其他子目錄，e.g., containing software bundled with OMNeT++)(註*2-6)

(譯 註*2-6：這句不太確定故保留英文)

  omnetpp/         OMNeT++ 根目錄
    bin/           OMNeT++ 可執行檔
    include/       模擬模型的標頭檔
    lib/           函式庫檔案
    images/        網路的圖示與背景圖片
    doc/           手冊, readme, 版權, APIs, 等等.
      ide-customization-guide/ how to write new wizards for the IDE
      ide-developersguide/ writing extensions for the IDE
      manual/      manual in HTML
      migration/   如何將3.x版的模擬程式轉換成4.0版
      ned2/        NED檔案的XML語法的DTD定義
      tictoc-tutorial/  OMNeT++ 使用簡介
      api/         API reference in HTML
      nedxml-api/  API reference for the NEDXML library
      parsim-api/  API reference for the parallel simulation library
    migrate/       tools to help model migration from 3.x to 4.0 version
    src/           OMNeT++ 原始碼
      sim/         模擬核心程式
        parsim/    files for distributed execution
        netbuilder/files for dynamically reading NED files
      envir/       common code for user interfaces
      cmdenv/      command-line user interface
      tkenv/       Tcl/Tk-based user interface
      nedxml/      NEDXML library, nedtool, opp_msgc
      scave/       result analysis library
      eventlog/    eventlog processing library
      layout/      graph layouter for network graphics
      common/      common library
      utils/       opp_makemake, opp_test, etc.
    test/          regression test suite
      core/        tests for the simulation library
      anim/        tests for graphics and animation
      dist/        tests for the built-in distributions
      makemake/    tests for opp_makemake
      ...

以Eclipse為基礎開發的模擬整合開發環境(Simulation IDE)放在ide目錄中。

    ide/           Simulation IDE
      features/    Eclipse feature definitions
      plugins/     IDE plugins (extensions to the IDE can be dropped here)
      ...

OMNeT++ Windows版本包含MinGW gcc編輯器，同時也包含一個MSYS，它提供一組常常被Makefiles使用的Unix工具。MSYS子目錄同時也包含其他編譯與執行OMNeT++所需要的第三方開源碼函式庫。

    tools/       Platform specific tools and compilers (e.g. MinGW/MSYS on Windows)

範例程式放在samples目錄中。

    samples/     directories for sample simulations
      aloha/     models the Aloha protocol
      cqn/       Closed Queueing Network
      ...

contrib目錄包含一些來自OMNeT++社群的模擬工具與素材

    contrib/     directory for contributed material
      akaroa/    Patch to compile akaroa on newer gcc systems
      jsimplemodule/  Write simple modules in Java
      topologyexport/  Export the topology of a model in runtime
      ...

2 Overview

2.1 Modeling Concepts

An OMNeT++ model consists of modules that communicate with message passing. The active modules are termed simple modules; they are written in C++, using the simulation class library. Simple modules can be grouped into compound modules and so forth; the number of hierarchy levels is unlimited. The whole model, called network in OMNeT++, is itself a compound module. Messages can be sent either via connections that span modules or directly to other modules. The concept of simple and compound modules is similar to DEVS atomic and coupled models.

In Fig. below, boxes represent simple modules (gray background) and compound modules. Arrows connecting small boxes represent connections and gates.

over-modules

Figure: Simple and compound modules

Modules communicate with messages that may contain arbitrary data, in addition to usual attributes such as a timestamp. Simple modules typically send messages via gates, but it is also possible to send them directly to their destination modules. Gates are the input and output interfaces of modules: messages are sent through output gates and arrive through input gates. An input gate and output gate can be linked by a connection. Connections are created within a single level of module hierarchy; within a compound module, corresponding gates of two submodules, or a gate of one submodule and a gate of the compound module can be connected. Connections spanning hierarchy levels are not permitted, as they would hinder model reuse. Because of the hierarchical structure of the model, messages typically travel through a chain of connections, starting and arriving in simple modules. Compound modules act like “cardboard boxes” in the model, transparently relaying messages between their inner realm and the outside world. Parameters such as propagation delay, data rate and bit error rate, can be assigned to connections. One can also define connection types with specific properties (termed channels) and reuse them in several places. Modules can have parameters. Parameters are used mainly to pass configuration data to simple modules, and to help define model topology. Parameters can take string, numeric, or boolean values. Because parameters are represented as objects in the program, parameters — in addition to holding constants — may transparently act as sources of random numbers, with the actual distributions provided with the model configuration. They may interactively prompt the user for the value, and they might also hold expressions referencing other parameters. Compound modules may pass parameters or expressions of parameters to their submodules.

 

OMNeT++ provides efficient tools for the user to describe the structure of the actual system. Some of the main features are the following:

  • hierarchically nested modules
  • modules are instances of module types
  • modules communicate with messages through channels
    flexible module parameters
  • topology description language

2.1.1 Hierarchical Modules

An OMNeT++ model consists of hierarchically nested modules that communicate by passing messages to each other. OMNeT++ models are often referred to as networks. The top level module is the system module. The system module contains submodules that can also contain submodules themselves (Fig. below). The depth of module nesting is unlimited, allowing the user to reflect the logical structure of the actual system in the model structure.

 

Model structure is described in OMNeT++’s NED language.

Modules that contain submodules are termed compound modules, as opposed to simple modules at the lowest level of the module hierarchy. Simple modules contain the algorithms of the model. The user implements the simple modules in C++, using the OMNeT++ simulation class library.

2.1.2 Module Types

Both simple and compound modules are instances of module types. In describing the model, the user defines module types; instances of these module types serve as components for more complex module types. Finally, the user creates the system module as an instance of a previously defined module type; all modules of the network are instantiated as submodules and sub-submodules of the system module.

 

When a module type is used as a building block, it makes no difference whether it is a simple or compound module. This allows the user to split a simple module into several simple modules embedded into a compound module, or vice versa, to aggregate the functionality of a compound module into a single simple module, without affecting existing users of the module type.

Module types can be stored in files separately from the place of their actual usage. This means that the user can group existing module types and create component libraries. This feature will be discussed later, in chapter [10].

 

2.1.3 Messages, Gates, Links

Modules communicate by exchanging messages. In an actual simulation, messages can represent frames or packets in a computer network, jobs or customers in a queuing network or other types of mobile entities. Messages can contain arbitrarily complex data structures. Simple modules can send messages either directly to their destination or along a predefined path, through gates and connections.

The “local simulation time” of a module advances when the module receives a message. The message can arrive from another module or from the same module (self-messages are used to implement timers).

 

Gates are the input and output interfaces of modules; messages are sent out through output gates and arrive through input gates.

Each connection (also called link) is created within a single level of the module hierarchy: within a compound module, one can connect the corresponding gates of two submodules, or a gate of one submodule and a gate of the compound module (Fig. below).

Because of the hierarchical structure of the model, messages typically travel through a series of connections, starting and arriving in simple modules. Compound modules act like “cardboard boxes” in the model, transparently relaying messages between their inner realm and the outside world.

2.1.4 Modeling of Packet Transmissions

To facilitate the modeling of communication networks, connections can be used to model physical links. Connections support the following parameters: data rate, propagation delay, bit error rate and packet error rate, and may be disabled. These parameters and the underlying algorithms are encapsulated into channel objects. The user can parameterize the channel types provided by OMNeT++, and also create new ones.

When data rates are in use, a packet object is by default delivered to the target module at the simulation time that corresponds to the end of the packet reception. Since this behavior is not suitable for the modeling of some protocols (e.g. half-duplex Ethernet), OMNeT++ provides the possibility for the target module to specify that it wants the packet object to be delivered to it when the packet reception starts.

2.1.5 Parameters

Modules can have parameters. Parameters can be assigned in either the NED files or the configuration file omnetpp.ini.

Parameters can be used to customize simple module behavior, and to parameterize the model topology.

Parameters can take string, numeric or boolean values, or can contain XML data trees. Numeric values include expressions using other parameters and calling C functions, random variables from different distributions, and values input interactively by the user.

Numeric-valued parameters can be used to construct topologies in a flexible way. Within a compound module, parameters can define the number of submodules, number of gates, and the way the internal connections are made.

2.1.6 Topology Description Method

The user defines the structure of the model in NED language descriptions (Network Description). The NED language will be discussed in detail in chapter [3].

2.2 Programming the Algorithms

The simple modules of a model contain algorithms as C++ functions. The full flexibility and power of the programming language can be used, supported by the OMNeT++ simulation class library. The simulation programmer can choose between event-driven and process-style description, and freely use object-oriented concepts (inheritance, polymorphism etc) and design patterns to extend the functionality of the simulator.

Simulation objects (messages, modules, queues etc.) are represented by C++ classes. They have been designed to work together efficiently, creating a powerful simulation programming framework. The following classes are part of the simulation class library:

  • module, gate, parameter, channel
  • message, packet
  • container classes (e.g. queue, array)
  • data collection classes
  • statistic and distribution estimation classes (histograms, P2 algorithm for calculating quantiles etc.)
  • transient detection and result accuracy detection classes

The classes are also specially instrumented, allowing one to traverse objects of a running simulation and display information about them such as name, class name, state variables or contents. This feature makes it possible to create a simulation GUI where all internals of the simulation are visible.

2.3 Using OMNeT++

2.3.1 Building and Running Simulations

This section provides insights into working with OMNeT++ in practice. Issues such as model files and compiling and running simulations are discussed.

An OMNeT++ model consists of the following parts:

  • NED language topology description(s) (.ned files) that describe the module structure with parameters, gates, etc. NED files can be written using any text editor, but the OMNeT++ IDE provides excellent support for two-way graphical and text editing.
  • Message definitions (.msg files). You can define various message types and add data fields to them. OMNeT++ will translate message definitions into full-fledged C++ classes.
  • Simple module sources. They are C++ files, with .h/.cc suffix.

The simulation system provides the following components:

  • Simulation kernel. This contains the code that manages the simulation and the simulation class library. It is written in C++, compiled into a shared or static library.
  • User interfaces. OMNeT++ user interfaces are used in simulation execution, to facilitate debugging, demonstration, or batch execution of simulations. They are written in C++, compiled into libraries.

Simulation programs are built from the above components. First, .msg files are translated into C++ code using the opp_msgc. program. Then all C++ sources are compiled and linked with the simulation kernel and a user interface library to form a simulation executable or shared library. NED files are loaded dynamically in their original text forms when the simulation program starts.

Running the Simulation and Analyzing the Results

The simulation may be compiled as a standalone program executable; thus it can be run on other machines without OMNeT++ being present, or it can be created as a shared library. In this case the OMNeT++ shared libraries must be present on that system. When the program is started, it first reads all NED files containing your model topology, then it reads a configuration file (usually calledomnetpp.ini). This file contains settings that control how the simulation is executed, values for model parameters, etc. The configuration file can also prescribe several simulation runs; in the simplest case, they will be executed by the simulation program one after another.

The output of the simulation is written into result files: output vector files, output scalar files, and possibly the user’s own output files. OMNeT++ contains an Integrated Development Environment (IDE) that provides rich environment for analyzing these files. Output files are line-oriented text files which makes it possible to process them with a variety of tools and programming languages as well, including Matlab, GNU R, Perl, Python, and spreadsheet programs.

User Interfaces

The primary purpose of user interfaces is to make the internals of the model visible to the user, to control simulation execution, and possibly allow the user to intervene by changing variables/objects inside the model. This is very important in the development/debugging phase of the simulation project. Equally important, a hands-on experience allows the user to get a feel of the model’s behavior. The graphical user interface can also be used to demonstrate a model’s operation.

The same simulation model can be executed with various user interfaces, with no change in the model files themselves. The user would typically test and debug the simulation with a powerful graphical user interface, and finally run it with a simple, fast user interface that supports batch execution.

Component Libraries

Module types can be stored in files separate from the place of their actual use, enabling the user to group existing module types and create component libraries.

Universal Standalone Simulation Programs

A simulation executable can store several independent models that use the same set of simple modules. The user can specify in the configuration file which model is to be run. This allows one to build one large executable that contains several simulation models, and distribute it as a standalone simulation tool. The flexibility of the topology description language also supports this approach.

2.3.2 What Is in the Distribution

If you installed the source distribution, the OMNeT++ directory on your system should contain the following subdirectories. (If you installed a precompiled distribution, some of the directories may be missing, or there might be additional directories, e.g. containing software bundled with OMNeT++.)

The simulation system itself:

  omnetpp/         OMNeT++ root directory
    bin/           OMNeT++ executables
    include/       header files for simulation models
    lib/           library files
    images/        icons and backgrounds for network graphics
    doc/           manuals, readme files, license, APIs, etc.
      ide-customization-guide/ how to write new wizards for the IDE
      ide-developersguide/ writing extensions for the IDE
      manual/      manual in HTML
      migration/   how to migrate your models from 3.x to 4.0 version
      ned2/        DTD definition of the XML syntax for NED files
      tictoc-tutorial/  introduction into using OMNeT++
      api/         API reference in HTML
      nedxml-api/  API reference for the NEDXML library
      parsim-api/  API reference for the parallel simulation library
    migrate/       tools to help model migration from 3.x to 4.0 version
    src/           OMNeT++ sources
      sim/         simulation kernel
        parsim/    files for distributed execution
        netbuilder/files for dynamically reading NED files
      envir/       common code for user interfaces
      cmdenv/      command-line user interface
      tkenv/       Tcl/Tk-based user interface
      nedxml/      NEDXML library, nedtool, opp_msgc
      scave/       result analysis library
      eventlog/    eventlog processing library
      layout/      graph layouter for network graphics
      common/      common library
      utils/       opp_makemake, opp_test, etc.
    test/          regression test suite
      core/        tests for the simulation library
      anim/        tests for graphics and animation
      dist/        tests for the built-in distributions
      makemake/    tests for opp_makemake
      ...

The Eclipse-based Simulation IDE is in the ide directory.

    ide/           Simulation IDE
      features/    Eclipse feature definitions
      plugins/     IDE plugins (extensions to the IDE can be dropped here)
      ...

The Windows version of OMNeT++ contains a redistribution of the MinGW gcc compiler, together with a copy of MSYS that provides Unix tools commonly used in Makefiles. The MSYS directory also contains various 3rd party open-source libraries needed to compile and run OMNeT++.

    tools/       Platform specific tools and compilers (e.g. MinGW/MSYS on Windows)

Sample simulations are in the samples directory.

    samples/     directories for sample simulations
      aloha/     models the Aloha protocol
      cqn/       Closed Queueing Network
      ...

The contrib directory contains material from the OMNeT++ community.

    contrib/     directory for contributed material
      akaroa/    Patch to compile akaroa on newer gcc systems
      jsimplemodule/  Write simple modules in Java
      topologyexport/  Export the topology of a model in runtime
      ...