Eclipse MOSAIC Application Simulator

The Application Simulator plays an important role in the simulation of vehicles and its functions. It provides the capability to model the application logic for different simulation units (e.g. vehicles, road side units (RSUs), traffic lights, and others) as well as possible interaction attempts between the units via different communication links.

Installation

This simulator does not need to be installed. It is delivered as part of the Eclipse MOSAIC installation package.

Configuration

The Application simulator offers configuration possibilities for several aspects, e.g.

1. the simulator itself
2. the developed and simulated application(s) (depending on the application)
3. the mapping.

In terms of the scenario folder structure, the configuration files are located in the folders, as outlined in the overview:

└─ <scenario_name>
   ├─ application
   |  ├─ application_config.json ............. Configuration file for the application simulator.
   |  ├─ <scenario_name>.db .................. Database file for navigation.
   |  ├─ YourApplication.jar ................. Application(s) to be simulated.
   |  └─ your_application_config.json ........ Optional configuration for application(s).
   └─ mapping
      └─ mapping_config.json ................. Configuration file for the application mapping.

The Application Simulator is configured in the file <scenario_name>/application/application_config.json. It is not necessary to provide the file, as in this case of a non-existing file, the following default configuration options are used:

{
    "messageCacheTime": "30s",
    "encodePayloads": true,
    "navigationConfiguration" : {
        "type": "database"
    }
}

Furthermore, depending on the deployed Applications, the applications itself may offer configuration options in custom configuration files (e.g. EtsiApplication.json or EtsiApplication_veh_0.json - see below).

Application Architecture

Each simulation unit (e.g. vehicle, RSU, traffic light ..) can have different applications (depending on their application Mapping. The applications for the units are basically compiled JAVA classes, which extend the abstract class AbstractApplication. Those classes have to be deployed as pre-compiled JAR files into the application folder of the simulated scenario.

Application Operating System

The AbstractApplication possesses a unit-specific OperatingSystem, which allows interactions with the simulated parameters. The operating system provides access to information like the current time or position of the units and could control unit-specific actions (like slowDown() for vehicles).

As the interaction types for navigation (retrieving road network information and calculating routes) and communication (preparing and sending messages) are more complex, they are separated into the specific modules NavigationModule (Navigation + Routing for vehicles) / RoutingModule (Routing-only for static units) and AdHocModule / CellModule with APIs dedicated to their purpose.

The following table lists all modules a unit’s operating system could provide.

Basic Applications

Eclipse MOSAIC is shipped with several example applications which can be loaded on the vehicles. Next to the applications shipped with the tutorial scenarios Barnim and Tiergarten, there are further example applications to be found on our website.

Additionally, we provide an ETSI conform application which implement specific CAM generation rules for vehicles (org.eclipse.mosaic.fed.application.app.etsi.VehicleCamSendingApp), which is described in the following:

ETSI Application for vehicles

This application generates ETSI data for its simulation unit (e.g. heading, position, speed and time for vehicles). According to its configuration, the application then sends out CAMs to other vehicles in range. Note that the messages are only send when the time lies between the configured minimum and maximum interval.

Currently, the default configuration (EtsiApplication.json) for the ETSI application looks like this:

{
    /* The minimal length in bytes assumed for the payload to be send with each CAM. */
    "minimalPayloadLength": 200,
    /* The maximum time offset (here 1 second) of sending CA-messages 
     * (the offset will be different for every single vehicle to avoid interference) */
    "maxStartOffset": "1s",  
    /* CAMs are sent at most every 1 second */
    "minInterval": "500ms",
    /* CAMs are sent at least every 1 second */
    "maxInterval": "1s",
    /* CAMs are sent when the position of the vehicle changes at least about 4 meters */
    "positionChange": 4,
    /* CAMs are sent when the heading of the vehicle changes at least about 4 degrees */
    "headingChange": 4,
    /* CAMs are sent when the velocity of the vehicle changes at least about 0.5 m/s */
    "velocityChange": 0.5
}

The CAMs sent out by this application consist of four parts:

• Header with generic information
• MessageBody
• TaggedValue list

First of all, generic information like protocol version and creation time stamp are transmitted. Normally this data set follows a network beacon, already containing data like position and speed. Nevertheless this functionality must be implemented in the network layer, i.e. in the network simulator. At the moment this is not supported and is therefore compensated in the next message part, the message body. The body contains vehicle awareness data, including data like vehicle width, length, position, speed, type and heading. However, the specification is not completely implemented. Last but not least a message can contain optional data.