# OMNeT++: a discrete event simulator you can embed in your own code

> OMNeT++ is a component based simulation environment with a strong GUI and an embeddable kernel, built mainly for communication networks and also used for queueing, hardware and business process models. Adoption means building from source with a configure step and accepting the Academic Public License.

**omnetpp/omnetpp** — OMNeT++ Discrete Event Simulator

- Repository: https://github.com/omnetpp/omnetpp
- Website: https://omnetpp.org
- Stars: 763 · Forks: 179
- Language: Java
- License: not declared
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/omnetpp-omnetpp

## A simulation environment whose kernel can be embedded

OMNeT++ is described as a public-source, component-based, modular simulation environment with strong GUI support and an embeddable simulation kernel. Those two halves matter. The GUI half is what most people meet first: a graphical environment for building and running network models. The embeddable kernel half is what makes it more than a modelling GUI. Because the kernel can be linked into another program, the same event scheduling machinery that drives a model can drive a simulator that is one component of a larger system.

The mechanism underneath is discrete event simulation. Instead of stepping a fixed timestep, the simulation advances from event to event, which is why the project suits problems where the interesting behaviour lives in message exchanges rather than in continuous time. The kernel is the component that owns the event queue, the simulation clock and the module hierarchy.

The top-level layout reflects the split. src/ holds the kernel and framework sources, include/ the public headers, ui/ the IDE front end, python/ the scripting layer, releng/ the release engineering tooling, and doc/ the documentation sources that the Installation Guide is generated from. The repository's own language field names Java while the topic list includes c-plus-plus, so a Java presence sits alongside the C++ core.

## Communication networks first, other domains second

The project's primary application area is the simulation of communication networks, and the documentation also records successful use in other areas: IT systems, queueing networks, hardware architectures and business processes.

The samples directory shows how broad that range actually is in practice. There are aloha/ and cqn/ for classic queueing and multiple access models, petrinets/ for Petri net style modelling, fifo/ for a minimal queue, dyna/ for dynamic network topologies, routing/ and sockets/ for protocol and transport behaviour, hypercube/ for interconnection networks, database/ for data store models, and openstreetmap/ plus osg-earth/ for geographic and three dimensional scenes. histograms and resultfiles directories handle measurement output, while embedding/ and embedding2/ show the kernel being used as a library rather than through the IDE.

Two observations follow. First, the domain coverage is genuine rather than aspirational, because the samples are part of the repository and the Makefile wires the samples directory into the build when it exists. Second, the osg and openstreetmap samples sit on top of third party 3D rendering, which tells you a model can be visually rich without that being the point of the tool.

## Cloning is followed by configure.user and the Installation Guide

The installation instructions are short because the real procedure lives in a separate document. After cloning the repository, you create a local copy of the configure.user file:

```bash
    cd omnetpp
    cp configure.user.dist configure.user
```

The repository ships configure.user.dist as a template, and copying it is what gives you a file the configure script can read and adjust. The steps that follow point to the Installation Guide of the last release, hosted as a PDF and generated from the sources in doc/src/installguide. That guide covers operating system specific dependency installation, build option selection and compilation.

So the honest description of the setup cost is: this is a source build with a configuration step, not a package you can install and run. The presence of install.sh and setenv at the top level suggests helper scripts for the environment and install path, and the presence of a Python directory points to a scripting layer, but the README does not give a single command that produces a working installation. Plan for a compiler toolchain, the dependencies named in the Installation Guide, and a few minutes with the PDF open beside you.

For anyone coming from a package manager habit, that is the main friction point, and it is worth knowing before the first afternoon is spent.

## Makefile.inc is the gate every build passes through

The top-level Makefile is a thin wrapper that hands off to a generated include file, and the guard is explicit. If Makefile.inc does not exist, the build stops with an instruction to run ./configure. The file is generated by the configure step that follows the configure.user copy, so a build attempted out of order fails immediately and with a clear message rather than half way through compilation.

The default target is worth reading closely, because it tells you what a full build produces:

```bash
all: allmodes
```

The allmodes target builds release and debug mode executables, so a first make produces two sets of binaries rather than one. A specific MODE value switches the default to a single build. There is a components target that pulls in base, and a help target that prints the available targets and variables. The Makefile also adds the samples and test directories as dependencies of components when those directories exist, which is how the model library gets built alongside the framework.

The structure is conservative and script friendly, which is what you want in a project consumed by CI systems and course environments. The cost is that nothing about the build is self describing: you are expected to read the make help output rather than guess at flags, and the generated Makefile.inc is where the actual toolchain paths live.

## The samples tree is the tutorial, and the GUI is optional

Newcomers to OMNeT++ are pointed to the main website for documentation, tutorials, introductory materials, release downloads and the model catalog. The repository itself supplies the samples directory as the hands-on material, and its own samples/README is the entry point.

The samples cover a range of granularities. Some are self contained exercises, others are the building blocks that the queueinglib and queueinglibext libraries extend, and the embedding directories show a model embedded into an application. The neddemo directory is the smallest complete case, suitable as a first run when you want to see output before you read about network configuration.

The GUI is strong in this project, which is unusual for a simulation framework that is fundamentally a kernel. That support is what lets you inspect a running model's internals while it runs, rather than only reading scalar results afterwards. The practical caveat is that the GUI and the kernel are separable, and the embedding samples exist precisely because not every deployment has a display. A team that wants to run a hundred models in parallel on a cluster is using a different surface of the same project than a student clicking through a tutorial, and the repository supports both without pretending they are the same task.

## An Academic Public License and a release line that moves

The licence is the first thing to settle. The README states that OMNeT++ is distributed under the Academic Public License, with the text referenced from doc/License. That is a source-available academic licence with obligations attached to distribution and modification, and it is not MIT, not Apache and not BSD. If you are shipping OMNeT++ inside a commercial product, read the licence text in doc/License and settle that question with whoever owns licensing in your organisation. Nothing in the repository offers a permissive alternative for the core.

Release activity, by contrast, is easy to characterise. The most recent tags are omnetpp-6.4.0aipre2 from 2026-05-27, omnetpp-6.4.0 from 2026-05-07, and omnetpp-6.3.0 from 2025-11-12. The default branch is omnetpp-6.x, the repository is not archived, and the last push was on 2026-05-27.

That pattern suggests a steady cadence with room for preview builds. The 6.4.0aipre2 tag, whose title names an AI and LLM technology preview integration, is the interesting one for anyone doing model work: it marks a specific experimental direction rather than a general release. The corresponding source files MIGRATION, WHATSNEW.md, Version and INSTALL.md in the top level are where upgrade notes live, and those are the files to read before moving a build from one minor version to the next.

## Conclusion

OMNeT++ suits research groups and engineers who need to model networks, queueing systems or business processes and want a GUI alongside a kernel they can embed. It does not suit teams that want a pip install or a permissive licence, since the project is distributed under the Academic Public License and building it requires the configure step and a local configure.user file. Before committing, follow the Installation Guide in the last release, compile the release and debug modes the Makefile offers, and confirm the sample models under samples/ run in your environment.

## FAQ

### How do I build OMNeT++ from source?

Clone the repository, copy the template config file with cp configure.user.dist configure.user, then follow the Installation Guide of the last release for dependency installation and compilation. The top-level Makefile refuses to build until ./configure has generated Makefile.inc.

### What licence is OMNeT++ distributed under?

The project is distributed under the Academic Public License, with the licence text referenced from the doc/License file in the repository. It is not a permissive open source licence, so redistribution terms deserve a close read before commercial use.

### Can the OMNeT++ simulation kernel be used outside the IDE?

Yes. The project describes itself as having an embeddable simulation kernel, and the samples directory includes embedding/ and embedding2/ examples that use the kernel from application code rather than only through the GUI.

### Which domains does OMNeT++ model?

The primary application area is communication network simulation, and the documentation also records use in IT systems, queueing networks, hardware architectures and business processes. The samples directory includes aloha, cqn, petrinets, fifo, routing, sockets, queueinglib and openstreetmap models.

## Sources

- [Issues](https://github.com/omnetpp/omnetpp/issues)
- [omnetpp/omnetpp on GitHub](https://github.com/omnetpp/omnetpp)
- [Project website](https://omnetpp.org)
- [README](https://github.com/omnetpp/omnetpp/blob/omnetpp-6.x/README.md)
- [Releases](https://github.com/omnetpp/omnetpp/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/omnetpp-omnetpp