Upgrading

Adapting user-written models to work with newer Veins versions.

Since Veins 5.0, releases follow a semantic versioning scheme: Each release is assigned a version number consisting of two or three parts seperated by dots (x.y or x.y.z). Newer releases carry higher version numbers, with the most significant number being the one on the left (2.0.0 is newer than 1.10).

Any user-written model that was written for a specific Veins release should also work with any newer release that has the same major version number (the x part). Releases that only introduce new features are assigned newer minor version numbers (the y part). Bugfix releases are assigned a patch number (the z part).

Preview versions are assigned a label that does not follow this scheme (e.g., 5.0-alpha2). The label is an indication of what release the preview will correspond to (in this case: the first Veins release with a major version of 5). Yet, no assumptions should be made with respect to compatibility or stability of these versions.

Note: In particular, preview versions should not be relied upon for producing valid results.

Upgrading from Veins 4 to Veins 5

A number of backwards-incompatible changes are introduced with Veins 5. These changes require user-written models to be adapted and are pointed out below.

Additionally, the code of Veins 5 is structured and written slightly differently to that of Veins 4. For ease of reading, it is recommended to follow this structure for user-written code as well. These changes are pointed out below as well.

  • upgrade external dependencies to supported versions
    • OMNeT++ 5.5.1
    • SUMO 1.2.0
    • (optional, for INET 4 support: INET 4.1.0 or 4.1.1)
    • (optional, for INET 3 support: INET 3.6.5)
    • (optional, for platooning simulation: Plexe 3.0 or a pre-release thereof)
    • (optional, for visible light communication simulation: Veins VLC 1.0 or a pre-release thereof)
    • (optional, for 3gpp mobile broadband simulation: SimuLTE veins-integration branch)
  • change indentation of lines to 4 spaces
    • to have this done automatically for you, install the uncrustify code formatter (version 0.68.1) and run make formatting
    • if you want to bring your code further in line with the Veins 5 code style, install the clang-format code formatter (version 6.0.0) and run make formatting-strict
  • include #include "veins/veins.h" at the top of every header file
    • consider checking for a compatible Veins version by ensuring that the VEINS_VERSION_MAJOR macro is set as expected and the VEINS_VERSION_MINOR is no smaller than expected.
  • in your config.xml, add thresholding="true" where appropriate if you want to make use of the faster PHY implementation of Veins 5
    • this parameter is available for the following analogue models:
    • <AnalogueModel type="SimplePathlossModel" thresholding="true">
    • <AnalogueModel type="SimpleObstacleShadowing" thresholding="true">
    • <AnalogueModel type="VehicleObstacleShadowing" thresholding="true">
  • remove the debug and memcheck scripts
    • their functionality has been integrated into the run script
    • to run a simulation in debug mode and with gdb attached as a debugger, use ./run --debug --tool gdb -- -u Cmdenv
    • similar considerations apply for valgrind --tool=memcheck or lldb
  • remove .debug and .coreDebug parameters from your .ini file (and, optionally, your own simulation models); remove #define DBG statements from your own simulation models
    • selective logging of debug information is now being taken care of by macros like EV_DEBUG << "..." or EV_INFO << "..." instead. See the OMNeT++ user manual for details
    • use .ini statements like **.manager.cmdenv-log-level = warn to selectively set the amount of debug information printed
    • use .ini statements like cmdenv-express-mode = false and cmdenv-log-prefix = "[%c%?-%l] t=%t %d (%f:%i) -> " to configure how debug information is printed
  • set .nic.phy80211p.antennaOffsetZ and .veinsmobility.hostPositionOffset as appropriate and set .veinsmobility.z = 0
    • this allows finer-grained manipulation of where an OMNeT++ host will be created in relation to a SUMO vehicle, as well as where the PHY layer's antenna will be created in relation to the OMNeT++ host.
  • in your .h files, replace include guards (#ifndef XYZ ... #define XYZ ... #endif) with #pragma once
  • if you wrote custom mobility models, note that mobility no longer enforces that orientation==direction; if your mobility model needs to enforce this, do it yourself.
  • in your simulation models, import namespace veins
  • rename WaveAppToMac1609_4Interface to DemoBaseApplLayerToMac1609_4Interface
  • remove explicit casts from par("...").longValue() to implicit casts from par("...")
  • do not subscribe to signals using a private member of type simsignalwrap_t that uses a macro like MIXIM_SIGNAL_MOBILITY_CHANGE_NAME
    • instead, directly use signal as BaseMobility::mobilityStateChangedSignal
  • rename mobility->getCurrentPosition() to mobility->getPositionAt(simTime())
  • rename WaveShortMessage to BaseFrame1609_4
  • rename BaseWaveApplLayer.h to DemoBaseApplLayer.h
  • replace use of assert with ASSERT
  • rename .nic.phy80211p.useThermalNoise to .nic.phy80211p.useNoiseFloor
  • rename .nic.phy80211p.thermalNoise to .nic.phy80211p.noiseFloor and pick a sane value
  • rename .nic.phy80211p.sensitivity to .nic.phy80211p.minPowerLevel and pick a sane value
  • rename mobility->getAngleRad() to mobility->getHeading().getRad();