Skip to main content

Platform Concept

The platform concept is shown in the following picture.

openPASS platform concept

The platform is built up in a modular manner. The simulation core calculates different simulation runs. Scenarios and agent components can connect to the core by standards and standardized interfaces such as ASAM OpenDRIVE, OpenSCENARIO and OSI as well as Modelica FMI and SSP. The openPASS Working Group (WG) provides simple examples of scenarios and agent components. Consequently, users can freely connect their own scenarios and agent components to the simulation core. Possible use cases of using openPASS are accident research, functional development, safety performance assessment, virtual testing and homologation.

Diagram containing interfaces of openPASS

Top-Level Architecture

Top level system architecture diagram

The two main parts of openPASS: the graphical user interface (GUI) and the simulation framework.

The GUI is intended to give the user an easy access to the configuration of experimental setups before the simulation. In order to perform a traffic simulation an input must be available, which can be prepared and offered by one of the GUI plugins. In the GUI, the users will conveniently select traffic scenarios, traffic participants (including vehicles, drivers and systems to be tested) as well as post-processing of the simulation results. OpenPASS simulation accepts open formats such as ASAM OpenDRIVE, OpenSCENARIO and several openPASS specific formats. Each file defines either simulation parameters, traffic scenario, traffic composition, events or other key data. It is built as a modular software allowing attachment of independent or dependent plugins. A plugin can read input data (e.g. from a PCM database ), process these data and prepare an experiment configuration, which can be understood by the simulation.

The simulation framework is a stand-alone executable (to be precise, two of them). It consists of:

The simulation is a mostly generic assembly of data I/O routines, scheduler and a collection of interfaces. The simulation manager is meant to only collect and organize input data. The simulation core is the one performing the actual simulation. A simulation manager can, if configured so, start several experiments in parallel by triggering several simulation cores.

The core modules and agent components belong to the simulation core application. Both communicate with the simulation core via interfaces and bound dynamically at runtime.

Core module diagram

Core modules are all singletons and used by the simulation core and/or agent components. These are necessary for every simulation to run and cover basic needs like e.g.:

On the other hand, agent components represent a composition of participants or agents. They define the behavior and dynamics of each agent. A set of such components is then called system.

Agent component diagram

Unlike core modules, components can be freely selected and assembled by the user according to his scope of application. A typical system would consist of a sensor perceiving the environment, an algorithm performing analysis of this environment and making decisions and a dynamics algorithm receiving directives from the algorithm and calculating the actual physical simulation step. When assembling a system, the user shall of course care about connecting the chosen component via signals, which are understood by the sender and the receiver.

Completing the loop back to the graphical UI, a plugin can await the completion of one or several experiments and collect the output produced by the simulation in order to evaluate and/or visualize the results.

Simulation Process from the User Perspective

User perspective of the simulation process
The illustration above shows the simulation process in openPASS. By configurations in the GUI the user set up the desired simulation run. Basically, the GUI supports the user to set up the simulation in accessing and writing XML, XODR and XOSC files. After the setup of the configuration files the simulation can be executed. As an output CSV and XML files are generated. For the future, the evaluation over the GUI should be available which is yet still under development.


The documentation of openPASS can be found here: openPASS Documentation. It consists of information about the installation, configuration and usage of openPASS.

Report a bug in GitLab

Back to the top