Omnet 4 Simulation Pltfm

OMNeT 4 ++ Simulation Platform This is a major revision of the whole simulation platform, with fundamental changes in nearly every component. Changes since version 3.4b2:GUI: An Eclipse-based comprehensive simulation IDE has been introduced to replace the previous standalone GUI programs gned, scalars and plove. The IDE supports all stages of a simulation project: developing, building, configuring and running simulation models, and analysing results. It also supports visualizing simulation execution traces as sequence charts, and generating documentation. We are also bundling version control (cvs, svn, git) Eclipse plug-ins with the IDE. The IDE is supported on the three major platforms, Linux, Mac OS X and Windows. Since Eclipse is extremely extensible, we expect that OMNeT++-based simulation frameworks will contribute their own custom wizards into the IDE. Tooling: ------On the Windows platform, we have standardized on using the MinGW compiler. We are bundling a version of MSys and MinGW with the distribution, along with MinGW versions of several open-source programs and libraries needed or found useful with OMNeT++, such as gdb, perl, libxml, gmp, graphviz, Tcl/Tk, svn and git. MinGW was chosen over Cygwin because MinGW builds and uses libraries in the native Windows (MSVC-compatible) binary format, and builds programs that execute without a Unix emulation layer. The MSVC compiler is only supported in the commercial version of OMNeT++. Build system: -----------In order to facilitate working with large simulation models like the INET Framework, the makefile generator opp_makemake has been extended with the --deep option. With --deep, opp_makemake generates a makefile that takes care of building a whole source directory tree. Another big change is out-of-directory builds for both the OMNeT++ libraries

and simulation models: object files and other by-products of the build process go in a separate directory tree (out/). Simulation models can now easily be compiled with debug/release compiler options, simply with the commands "make MODE=debug" and "make MODE=release"; there is no need to modify configure.user. Simulation kernel: ---------------Simulation kernel internals have been redesigned with memory efficiency in mind, to support large-scale simulations better. Techniques include string pooling (storing freqeuently occurring strings such as module, gate and parameter names only in one copy), shared parameter value instances, gate vector descriptors (gate name, type and size are only stored once for the whole gate vector), and optimal packing of object fields (e.g. packing several boolean variables into an unsigned int). The simulation kernel as a library has been made significantly easier to embed in other (non-OMNeT++) programs. The way of using the OMNeT++ simulation kernel as a plain C++ library has been documented in the Manual, and two corresponding code examples have been added to the distribution. There have been several complaints about precision loss due to simtime_t being represented with the C type "double". In 4.0, double has been replaced with an int64-based fixed-point representation; the precision can be configured in omnetpp.ini as a power of ten, with the default being picosecond resolution (1e-12). Regarding the API, several functions have been given better or more consistent names, with the most visible change being that getter methods have been prefixed with the word "get". Migration of simulation models to 4.0 is assisted by scripts that perform this renaming (and several other adjustments) in the source code. cMessage has been split into a base cMessage plus a cPacket class. The bit length, encapsulated message and error flag fields have been

moved to cPacket. Modules have now the possibility to receive nonzero-duration messages at the beginning of the reception; this is done by reconfiguring the gate object. sendDirect() calls now expect the propagation delay and transmission duration values in separate arguments; this was done to facilitate the animation of wireless transmissions later. NED: ---The NED language has been revised and significantly extended. An overview of changes: The language syntax has been changed to make it more consistent. A migration tool is provided to convert old NED files to the new syntax. A Java-like package system has been introduced to make the language scale to large model frameworks and to prevent name clashes; NED files files are now read from directory trees listed on the NEDPATH. Channels have been made first-class citizens. They can have arbitrary parameters like modules do, and may have custom C++ implementation classes. Three predefined channel types have been created, ned.IdealChannel, ned.DelayChannel and ned.DatarateChannel. Inheritance is now supported for module and channel types. Derived modules and channels may add new parameters and gates, may set or modify parameter values and gate vector size, and (in the case of compound modules) may add new submodules and connections. Inner types are now supported. This is most useful for making channel definitions local to the network definition that uses them. Module and channel interfaces have been introduced, to make "like"

relationships more explicit. Module and channel interfaces can be used as a placeholder where normally a module or channel type would be used, and the concrete module or channel type is determined at network setup time by a parameter. Concrete module types have to "implement" the interface they can substitute. Inout gates and bidirectional gates are now supported. In the C++ code, inout gates appear as (input,output) gate pairs. Parameters can now have default values. The default value can be overridden in the ini file. If the ini file does not assign any value to the parameter, the default values get used automatically. Support for arithmetic expressions has become more complete, e.g. string manipulation is also possible. It is possible to annotate module or channel types, parameters, gates and submodules with properties. Metadata can carry extra information for various tools, the runtime environment, or even for other modules in the model. Examples include display strings, parameter prompt string and unit of measurement. Default icons (in general, default display strings) are now supported. Display strings are represented as metadata annotation (@display property), which can be modified via inhertance. Ini files: ------Instead of runs, named configuration sections were introduced in the ini file. The concept of "runs" have been refined to provide parameter study support; Ini files now can specify parameter ranges and the runtime is able to explore them. The notion of experiment, measurement and replication was introduced to help the general workflow of result analysis.

Configuration options are now checked; mistyped configuration options are reported. Configuration options can be given on the command-line as well, overriding the values specified in the ini file. The new "fingerprint" ini file option allows for quick-and-simple regression tests. The fingerprint is basically a hash of event times and module IDs during the simulation, and it can detect if the simulation follows a different trajectory after a supposedly "harmless" code change. Result analysis: --------------The new result analysis tool in the IDE (which replaces plove and scave) supports the notion of experiments, measurements and replication. The IDE now stores all operations required to create a diagram or chart in a "recipe" file. It can recreate the charts and diagrams automatically after re-running the simulation or the whole experiment. The vector and scalar file format has changed to support the new features of the IDE. Vector files are now indexed for efficiency.