The platform concept is shown in the following picture.
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.
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 https://www.vufo.de/pcm/?lang=en ), 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 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.
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.
The documentation of openPASS can be found here: openPASS Documentation. It consists of information about the installation, configuration and usage of openPASS.