[{"authors":["fokus"],"categories":null,"content":"","date":-62135596800,"expirydate":-62135596800,"kind":"term","lang":"en","lastmod":-62135596800,"objectID":"cbf22d51976246e8f80b5f6a1df3bf83","permalink":"https://www.eclipse.org/mosaic/author/fraunhofer-fokus/","publishdate":"0001-01-01T00:00:00Z","relpermalink":"/mosaic/author/fraunhofer-fokus/","section":"authors","summary":"","tags":null,"title":"Fraunhofer FOKUS","type":"authors"},{"authors":null,"categories":null,"content":"Applications in Eclipse MOSAIC are simulated by the Application Simulator  . Such an application is programmed in Java and follows an event-based execution flow. Thereby, certain methods of the application are called by the Application Simulator upon corresponding events (the application \u0026ldquo;reacts\u0026rdquo;). To actively gain execution at some later point in time, an application can also schedule a generic event itself. When the application is executing, it has access to a set of methods, allowing to trigger actions like sensing messages or controlling the vehicle, influencing the current simulation (the application \u0026ldquo;acts\u0026rdquo;).\nDeveloping Applications Developing custom applications in Eclipse MOSAIC is rather easy. The best way to learn it is by looking at the source code of actual applications. For this purpose, we provide the source code of all tutorial applications and further examples.\nFor an easy understanding of the application API, the following questions and their answers should help:\n  What is required to get my own application to run in Eclipse MOSAIC? In Eclipse MOSAIC it is very easy to build your own application. First, it needs to inherit from the AbstractApplication class (see following section). Secondly, the application must be mapped to a vehicle (or RSU, or traffic light, \u0026hellip;) via the mapping configuration (see section mapping  ). Finally, the application must be compiled as a Jar-File and placed into the application directory of your scenario.\n  How can I access vehicle functions from within the application, such as sending V2X messages? Every applications has access to the OperatingSystem of the underlying unit which allows to change its state or to initiate actions, such as sending messages to other vehicles.\n  How can I react to events during the simulation, such as receiving V2X messages? For each application you decide, which events the application should listen to. For example, if your application needs to react upon incoming V2X messages, it simply implements the CommunicationApplication interface. In the following section you can find all available interfaces applications can implement.\n  Create a ’Hello world’ application based on Maven For this example you need to install Maven  which is used to resolve required MOSAIC dependencies and to compile your application Java code into a Jar file. Follow the steps to build an example application:\n Create a new folder HelloWorldApp: └─ HelloWorldApp ├─ src | └─ main | └─ java | └─ HelloWorldApp.java └─ pom.xml   Place a pom.xml with the following content: \u0026lt;?xml version=\u0026quot;1.0\u0026quot; encoding=\u0026quot;UTF-8\u0026quot;?\u0026gt; \u0026lt;project xmlns=\u0026quot;http://maven.apache.org/POM/4.0.0\u0026quot; xmlns:xsi=\u0026quot;http://www.w3.org/2001/XMLSchema-instance\u0026quot; xsi:schemaLocation=\u0026quot;http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd\u0026quot;\u0026gt; \u0026lt;modelVersion\u0026gt;4.0.0\u0026lt;/modelVersion\u0026gt; \u0026lt;groupId\u0026gt;org.eclipse.mosaic.app\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;HelloWorldApp\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;0.0.1\u0026lt;/version\u0026gt; \u0026lt;packaging\u0026gt;jar\u0026lt;/packaging\u0026gt; \u0026lt;dependencies\u0026gt; \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;org.eclipse.mosaic\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;mosaic-application\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;20.0\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; \u0026lt;/dependencies\u0026gt; \u0026lt;/project\u0026gt;   Create a new application in src/main/java/HelloWorldApp.java: import org.eclipse.mosaic.fed.application.app.AbstractApplication; import org.eclipse.mosaic.fed.application.app.api.VehicleApplication; import org.eclipse.mosaic.fed.application.app.api.os.VehicleOperatingSystem; import org.eclipse.mosaic.lib.objects.vehicle.VehicleData; import org.eclipse.mosaic.lib.util.scheduling.Event; public class HelloWorldApp extends AbstractApplication\u0026lt;VehicleOperatingSystem\u0026gt; implements VehicleApplication { @Override public void onStartup() { getLog().info(\u0026quot;Hello World!\u0026quot;); } @Override public void onVehicleUpdated(VehicleData previousVehicleData, VehicleData updatedVehicleData) { getLog().info(\u0026quot;Driving {} m/s.\u0026quot;, updatedVehicleData.getSpeed()); } @Override public void onShutdown() { getLog().info(\u0026quot;Good bye!\u0026quot;); } @Override public void processEvent(Event event) { // ... } }   Build the application using maven: mvn clean install   Copy the JAR file from target/HelloWorldApp-0.0.1.jar to the application directory of your simulation scenario. Use the fully qualified name HelloWorldApp in the mapping_config.json to load the application onto vehicles.  Application Interfaces You may have noticed that the HellowWorldApp extends from the class [...].AbstractApplication\u0026lt;OS\u0026gt;. In order to define the type of unit your application can run on, you need to speficy the operating system by choosing one of the following:\n VehicleOperatingSystem - for applications mapped to normal vehicles. ElectricVehicleOperatingSystem - for applications for vehicles with electro mobility features. RoadSideUnitOperatingSystem - for applications mapped to RSUs. TrafficLightOperatingSystem - for applications mapped to traffic lights. TrafficManagementCenterOperatingSystem - for applications mapped to TMCs. ChargingStationOperatingSystem - for applications mapped to charging stations.  See package: org.eclipse.mosaic.fed.application.app.api.os.*\nFurthermore, your application can implement the following 7 interfaces in order to get informed on specific events:\n VehicleApplication - get informed when information about the vehicles state is updated. ElectricVehicleApplication - get informed on electric vehicle specific events. CommunicationApplication - react on incoming V2X messages. MosaicApplication - get informed on Eclipse MOSAIC internal events. TrafficLightApplication - get noticed when the traffic light program is changed. ChargingStationApplication - react on state changes of the charging station. TrafficManagementCenterApplication - get informed on state changes of road infrastructure.  See package: org.eclipse.mosaic.fed.application.app.api.*\n Basic Functions and Concepts for Applications The following section describes how applications are implemented.\nEvent hooks Applications are implemented by reacting to specific events. Those events are, amongst others:\n The simulation has started: All static units (e.g. road side units) are set up (onStartup() is called) Once a vehicle has been added to the simulation, all its configured applications are initialized (onStartup() is called) The data of the vehicle has changed, e.g. after the traffic simulator has finished one simulationstep (onVehicleUpdated() is called). A unit has received a V2X message from another entity (onMessageReceived is called). A unit which has send a V2X message via a ITS-G5 topocast receives an acknowledgement (onAcknowledgementReceived() is called).  Another example:\n#mermaid-1603209753374{font-family:\"trebuchet ms\",verdana,arial;font-size:16px;fill:#333;}#mermaid-1603209753374 .error-icon{fill:#552222;}#mermaid-1603209753374 .error-text{fill:#552222;stroke:#552222;}#mermaid-1603209753374 .edge-thickness-normal{stroke-width:2px;}#mermaid-1603209753374 .edge-thickness-thick{stroke-width:3.5px;}#mermaid-1603209753374 .edge-pattern-solid{stroke-dasharray:0;}#mermaid-1603209753374 .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-1603209753374 .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-1603209753374 .marker{fill:#333333;}#mermaid-1603209753374 .marker.cross{stroke:#333333;}#mermaid-1603209753374 svg{font-family:\"trebuchet ms\",verdana,arial;font-size:16px;}#mermaid-1603209753374 .actor{stroke:hsl(259.6261682243,59.7765363128%,87.9019607843%);fill:#ECECFF;}#mermaid-1603209753374 text.actor \u0026gt; tspan{fill:black;stroke:none;}#mermaid-1603209753374 .actor-line{stroke:grey;}#mermaid-1603209753374 .messageLine0{stroke-width:1.5;stroke-dasharray:none;stroke:#333;}#mermaid-1603209753374 .messageLine1{stroke-width:1.5;stroke-dasharray:2,2;stroke:#333;}#mermaid-1603209753374 #arrowhead path{fill:#333;stroke:#333;}#mermaid-1603209753374 .sequenceNumber{fill:white;}#mermaid-1603209753374 #sequencenumber{fill:#333;}#mermaid-1603209753374 #crosshead path{fill:#333;stroke:#333;}#mermaid-1603209753374 .messageText{fill:#333;stroke:#333;}#mermaid-1603209753374 .labelBox{stroke:hsl(259.6261682243,59.7765363128%,87.9019607843%);fill:#ECECFF;}#mermaid-1603209753374 .labelText,#mermaid-1603209753374 .labelText \u0026gt; tspan{fill:black;stroke:none;}#mermaid-1603209753374 .loopText,#mermaid-1603209753374 .loopText \u0026gt; tspan{fill:black;stroke:none;}#mermaid-1603209753374 .loopLine{stroke-width:2px;stroke-dasharray:2,2;stroke:hsl(259.6261682243,59.7765363128%,87.9019607843%);fill:hsl(259.6261682243,59.7765363128%,87.9019607843%);}#mermaid-1603209753374 .note{stroke:#aaaa33;fill:#fff5ad;}#mermaid-1603209753374 .noteText,#mermaid-1603209753374 .noteText \u0026gt; tspan{fill:black;stroke:none;}#mermaid-1603209753374 .activation0{fill:#f4f4f4;stroke:#666;}#mermaid-1603209753374 .activation1{fill:#f4f4f4;stroke:#666;}#mermaid-1603209753374 .activation2{fill:#f4f4f4;stroke:#666;}#mermaid-1603209753374:root{--mermaid-font-family:\"trebuchet ms\",verdana,arial;}#mermaid-1603209753374 sequence{fill:apa;}RTIApplicationSimulatorApplication1Application2VehicleRegistrationonStartup()onStartup()VehicleUpdatesonVehicleUpdated()onVehicleUpdated()VehicleUpdatesonVehicleUpdated()onVehicleUpdated()sendV2xMessage()V2xMessageTransmissionV2xMessageReceiptiononMessageReceived()VehicleUpdates (remove)onShutdown()onShutdown()RTIApplicationSimulatorApplication1Application2   Example sequence of onStartup, onUpdate, onMessageReceived and onShutdown of two applications.\nA onStartup() method, which enables the ITS-G5 communication module of the unit, could be implemented the following:\n@Override public void onStartup() { getOs().getAdHocModule().enable(new AdHocModuleConfiguration() .addRadio().channel(AdHocChannel.CCH).power(50).create() ); }  A onMessageReceived() method, which reacts upon a DENM message, could be implemented as:\n@Override public void onMessageReceived(ReceivedV2xMessage receivedV2xMessage) { final V2xMessage msg = receivedV2xMessage.getMessage(); if (msg instanceof Denm) { Denm denm = (Denm)msg; GeoPoint eventLocation = denm.getEventLocation(); //TODO you can add further implementation here } }  Trigger own Events It is possible to trigger own events at specific times within the application. For this purpose, the application has access to an own event manager. Each event requires a simulation timestamp when it should be called, and an event processor.\nThe following code triggers an event in 10 seconds after the application has been initialied:\n@Override public void onStartup() { Event event = new Event(getOs().getSimulationTime() + 10 * TIME.SECOND, this); getOs().getEventManager().addEvent(event); } @Override public void processEvent(Event event) { getLog().info(\u0026quot;Event has been triggered\u0026quot;); // TODO }  To address a specific method to process the event, Java lambda expressions could be used:\n@Override public void onStartup() { Event event = new Event(getOs().getSimulationTime() + 10 * TIME.SECOND, this::mySpecificMethod); getOs().getEventManager().addEvent(event); } public void mySpecificMethod(Event event) { getLog().info(\u0026quot;Event has been triggered\u0026quot;); // TODO }  Using the Operating System Each application has access to the operating system of its unit. Depending on the type of unit, the operating system provides different methods. For example, an application which is mapped on vehicles, has access to the VehicleOperatingSystem by calling this.getOperatingSystem() (or this.getOs() to keep it short). The following examples show a bit of the capabilities the VehicleOperatingSystem provides:\nGet the current simulation time (in nanoseconds):\nlong time = this.getOs().getSimulationTime();  Return the name of the unit (e.g. \u0026ldquo;veh_0\u0026rdquo;):\nString nameOfUnit = this.getOs().getId();  Get access to vehicle data, such as speed, position, heading, and the like:\ndouble speed = this.getOs().getVehicleData().getSpeed(); GeoPoint position = this.getOs().getVehicleData().getPosition();  Change parameters of the vehicle during the simulation, such as its maximum speed:\nthis.getOs().requestVehicleParametersUpdate() .changeMaxSpeed(10) // m/s .changeMaxAcceleration(2.4) .apply();  Get the current lane index of the vehicle and change lane to left (within 5000 ms):\nint laneIndex = this.getOs().getRoadPosition().getLaneIndex(); int newLaneIndex = Math.max(0, laneIndex - 1); this.getOs().changeLane(newLaneIndex, 5000);  Sending a V2X message via ITS-G5 singlehop broadcast:\nMessageRouting routing = this.getOs().getAdHocModule().createMessageRouting().topoBroadCast(); V2xMessage message = new MyV2xMessage(routing); this.getOs().getAdHocModule().sendV2xMessage(message);  Park the vehicle in 200 meters at the right side of the road for 3 minutes:\ndouble distance = 200; double duration = 3 * 60 * 1000; IRoadPosition stopPosition = RoadPositionFactory.createAlongRoute( getOs().getNavigationModule().getRoadPosition(), getOs().getNavigationModule().getCurrentRoute(), 0, distance ); this.getOs().stop(distance, duration, Stop.StopMode.PARK);  Navigation The navigation of vehicles (i.e. calculation of routes) is handled completely by the Application Simulator  . Each vehicle is equipped with a navigation system which provides all required information and functions for navigational purposes:\n Retrieve the current position and heading of the vehicle. Get the target of the vehicle. Calculate various routes from the current position to an arbitrary target. Choose a suitable route out of existing ones from the current position to an arbitrary target. Switch onto a specific route.  In order to provide routing functionality, a map model based on Open Street Map data is used, which needs to be transformed before the simulation using scenario-convert. The map data including initial routes for vehicles is provided with the database file which needs to be located in mosaic/scenarios/\u0026lt;scenario_name\u0026gt;/application/\u0026lt;scenario_name\u0026gt;.db\nConfiguration If the database needs to be located somewhere else, the path can be specified in mosaic/scenarios/\u0026lt;scenario_name\u0026gt;/application/application_config.json:\n{ ... \u0026quot;navigationConfiguration\u0026quot;: { \u0026quot;databaseFile\u0026quot;: \u0026quot;path/to/scenario.db\u0026quot; } }  The following snippet show, how the navigation system can be used within an application:\n//get navigation module INavigationModule navigationModule = getOs().getNavigationModule(); //choose current target as target position RoutingPosition targetPosition = new RoutingPosition(navigationModule.getTargetPosition()); //set routing parameters to fastest route search RoutingParameters params = new RoutingParameters().costFunction(IRoutingCostFunction.Fastest); //calculate routes RoutingResponse response = navigationModule.calculateRoutes(targetPosition, params); //switch to best route if (response.getBestRoute() != null) { boolean routeSwitched = navigationModule.switchRoute(response.getBestRoute()); ... }  Access SUMO TraCI from applications If SUMO is used as a traffic simulator and a special functionality is required, the sendSumoTraciRequest function in the OperatingSystem can be used.\nThe function expects a string (a unique identifier which will be assigned to the response) and a byte array (representing the complete Traffic Control Interface (TraCI) request including the header). The message identifier can be an empty string.\nIn all cases the command will trigger a response. The application can receive the response from the method onSumoTraciResult. This method will receive a SumoTraciResult object. This response contains the specified identifier. The application must handle the identification process of the response itself.\n Be careful when using this interface and the TraCI commands. The commands are delivered to TraCI without any prior checks.\n   You can find the example application SumoTraciInteractionApp in the additional examples bundle on the DCAITI website.\n   Debugging of applications To debug an application, remote debugging needs to be used. The following steps need to be performed in order to debug the application:\n Open the application in your IDE. Modify your mosaic.sh or mosaic.bat by adding debug parameters to the java call:\njava -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=4100 ... Add a new debug profile in your IDE for remote debugging. Make sure to correctly configure port 4100 (or whichever port you provided in step 2). Launch Eclipse MOSAIC with the argument -w 0 to disable the watchdog timer otherwise it will interfere with debugging. Connect your debugger in your IDE with the running simulation.  ","date":1565049600,"expirydate":-62135596800,"kind":"section","lang":"en","lastmod":1565049600,"objectID":"f3e4e878d3a3df21f512128da34ee9b3","permalink":"https://www.eclipse.org/mosaic/docs/develop_applications/","publishdate":"2019-08-06T00:00:00Z","relpermalink":"/mosaic/docs/develop_applications/","section":"docs","summary":"Applications in Eclipse MOSAIC are simulated by the Application Simulator  . Such an application is programmed in Java and follows an event-based execution flow. Thereby, certain methods of the application are called by the Application Simulator upon corresponding events (the application \u0026ldquo;reacts\u0026rdquo;).","tags":null,"title":"Basics in Application Development","type":"docs"},{"authors":null,"categories":null,"content":" ","date":1593471600,"expirydate":-62135596800,"kind":"section","lang":"en","lastmod":1593471600,"objectID":"73996a350495164dd7fb2b4e81c403df","permalink":"https://www.eclipse.org/mosaic/docs/api_docs/","publishdate":"2020-06-30T00:00:00+01:00","relpermalink":"/mosaic/docs/api_docs/","section":"docs","summary":" ","tags":null,"title":"Javadoc of Eclipse MOSAIC source code","type":"docs"},{"authors":null,"categories":null,"content":"To run a simulation, a federation of simulators has to be created. This federation consists of one federate for each participating simulator. In the upper part of Figure 1, the inner structure of a federate is illustrated. It consists of the original simulator that is connected to its federate ambassador and an instance of an Eclipse MOSAIC ambassador. The federates run on top of the Eclipse MOSAIC Runtime Infrastructure (lower part of Figure 1) which offers services for federation-, interaction- and time management. The communication between the federates and the runtime infrastructure is enabled by ambassadors. More precisely, a federate that wants to access services of the RTI can use a designated RTI-Ambassador that provides access to the provided services. In the opposite direction, i.e. if the runtime infrastructure wants to invoke operations on the federate implementation, a federate ambassador is used. Each federate ambassador implements the same interface that is used by Eclipse MOSAIC to control the simulator and to provide interactions from other federates.\n Schematic illustration of Eclipse MOSAIC Runtime Infrastructure    Time Management The main problem in executing a federation is the synchronization of its federates. Each federate is a discrete-event simulator with an ordered event list from which sequentially the first event is processed. Consequently, the Time Management is necessary for coordinating the simulation and synchronizing participating federates. It assures that each federate processes its events in correct order.\nAccording to Fujimoto  the time management in a federated environment includes two key components: Interaction (Message) order and time stamps. Note that we usually use the word \u0026lsquo;intercation\u0026rsquo; when talking about communication between federates, \u0026lsquo;message\u0026rsquo; will be used in the context of (V2X)-communication.\nThe Interaction Order service is completely implemented in Eclipse MOSAIC with the following design rationale: Each request of a federate to execute a local event is mapped to a global event within the Time management. Such an event consists of three attributes: simulation time, priority, and lookahead time. The simulation time defines the time in the simulation at which the event has to be processed. The priority allows defining an order of events that are scheduled at the same time. The third attribute, the lookahead time, describes an idle period following after an event. It is used to signalize that no further event will be scheduled and no interaction will be sent within this period. All events are scheduled by storing them in an event list in ascending order according to their simulation time. In case of equal simulation times, they are ordered in descending order to their priority. A time management cycle consists of three steps.\n  The federate invokes a time management service to request its logical time to advance. While Time Advance Request (TAR) is more suitable for time-stepped simulators, Next Event Request (NER) is the preferred primitive for event-driven federates.\n  The RTI delivers certain interactions to the federate. Each federate receives the interactions in the processInteraction() method.\n  The RTI completes the cycle by invoking a federate defined procedure called Time Advance Grant to indicate the federate’s logical time has been advanced. Eclipse MOSAIC supports the sequential and the parallel conservative mechanism for advancing time.\n   Interaction Management The exchange of data among federates is offered by the Interaction Management using interactions. Eclipse MOSAIC and its federates are decoupled through a publish-subscribe paradigm provided by the Interaction Management. A published interaction is forwarded to each subscriber directly after it has been published. However, a receiving federate is not allowed to advance its time based on an interaction but must request a time advancement if necessary. An interaction consists of its creation time, an identifier describing its type, and optional data. Interactions to exchange traffic, network, vehicle, and sensor data are predefined. These interactions are used to define a standardized communication behaviour.\nSubscribe Interaction Before a federate can receive interactions, it has to subscribe to them. The Interaction Management offers two different ways to subscribe to certain interactions. A federate can either define a interaction type only to receive all interactions of this type or, additionally, define conditions to filter interactions by their content. If a federate is not longer interested in subscribed interactions, it can rescind its interest.\nPublish Interaction Each federate is allowed to publish any interaction at any valid time of the simulation. After a interaction is published, the Interaction Management forwards the interaction to each federate that has subscribed to this type of interaction. A federate receiving a interaction can ignore it or request to advance its local time to handle this interaction.\n Federation Management The Federation Management is responsible for the administration of participating federates. This includes deploying, starting, stopping, and undeploying federates in a distributed system. Before running a simulation, the Federation Management creates an empty federation. After that, federates join the federation. Already joined federates can be removed from a federation, if they are not necessary for the rest of the simulation. After a simulation is finished, the Federation Management frees used resources.\nCreate Federation Creates an empty federation. After a federation is created, it is possible to join federates.\nJoin Federation A joining simulator is defined by a unique name and a FederateHandle. This handle contains the information whether start-up and deployment of the simulator are required to be handled by the Federation Management. In this case, further deployment and start-up information are included.\nStop Federation After a simulation is finished, all joined federates are resigned and their used resources are freed. All references are removed and necessary tasks to stop and undeploy the federate are executed.\nImplementation Details When a simulator is about to join a federation, a FederateHandle is passed to the Federation Manage- ment. A handle includes a Federate Ambassador that is responsible for all communication with the RTI as well as all identifiers for interactions it wants to subscribe to. Additionally, it contains two flags indicating how the simulator is started and if the simulator needs to be deployed by the Federation Management. For the deployment, the handle consists a reference to the directory including all binaries and host parameters consisting of an address and a directory in which the simulator shall be deployed. To start a simulator a start-command is included.\nIf the simulator is running, its ambassador is registered for coordinating the simulator during the sim- ulation run. Afterwards, the Federation Management initiates the subscription to interactions on behalf of an ambassador. Otherwise, before the ambassador is registered, the Federation Management starts and, if necessary, deploys the simulator on a local or a remote machine and connects it to its ambassador. The connection is created by redirecting the output of the started simulator to its ambassador. Based on the incoming data, the Federate Ambassador is responsible for configuring its communication with the simulator.\nLocal Federation Management In case a simulator is to be deployed on a local machine, its binaries are copied into the simulation directory that is defined within the host parameters. Afterwards, using the start-command the simulator is started in a new process and its output is redirected to the ambassador. Additionally, a mapping between ambassador and process reference is stored. Finally, when the federate is resigned, the ambassador is called to shut down its corresponding simulator. Finally, the mapped process is killed and all copied files are removed.\nDistributed Federation Management To administrate simulators on remote hosts, the Federation Management uses the Secure Shell (SSH)  protocol to send commands and the associated Secure File Transfer Protocol (SFTP)  to transfer binaries. After a process is started remotely, a mapping between ambassador, its process id, and the host on which is running are stored. Finally, when the federate is resigned, the remotely running process is killed and all binaries are removed.\n","date":1565049600,"expirydate":-62135596800,"kind":"section","lang":"en","lastmod":1565049600,"objectID":"1c65951f20f713cdbe7d5eea3c44701f","permalink":"https://www.eclipse.org/mosaic/docs/extending_mosaic/","publishdate":"2019-08-06T00:00:00Z","relpermalink":"/mosaic/docs/extending_mosaic/","section":"docs","summary":"To run a simulation, a federation of simulators has to be created. This federation consists of one federate for each participating simulator. In the upper part of Figure 1, the inner structure of a federate is illustrated.","tags":null,"title":"Core Concepts","type":"docs"},{"authors":null,"categories":null,"content":"On the following pages we provide a complete documentation of configuration files:\n   Configuration File Documentation     scenario_config.json  Scenario Configuration     mapping/mapping_config.json  Mapping Configuration     environment/environment_config.json  Environment Simulator Configuration     sns/sns_config.json  SNS Configuration     cell/cell_config.json  Cell Simulator configuration     cell/regions.json  Cell Regions configuration     cell/network.json  Cell Network configuration     sumo/sumo_config.json  SUMO Ambassador Configuration      Readable Units Our configuration files accept readable units for some fields. If a field or attribute can be filled with values of type number or string (e.g. the maxSpeed of a vehicle in the Mapping configuration), you can write a number which then will be interpreted as the type as described in the documentation. Besides, you are able to input a readable text like e.g. \u0026quot;10 km\u0026quot; or \u0026quot;35 mph\u0026quot; which than will be converted automatically to the default unit. Following, you find a few examples:\n table { width: auto; min-width: 65%; }      String Input Number Input Default Unit     Distance       \u0026quot;10 km\u0026quot; 10000.0 m    \u0026quot;10 cm\u0026quot; 0.1 m    \u0026quot;0.5m\u0026quot; 0.5 m    \u0026quot;1 meter\u0026quot; 1.0 m   Speed       \u0026quot;10 km/h\u0026quot; 2.77 m/s    \u0026quot;10 m/s\u0026quot; 10.0 m/s    \u0026quot;35 mph\u0026quot; 15.6464 m/s   Time       \u0026quot;10 ms\u0026quot; 10_000_000 ns    \u0026quot;20 ns\u0026quot; 20 ns    \u0026quot;0.5h\u0026quot; 1_800_000_000_000 ns    \u0026quot;0.5 hours\u0026quot; 1_800_000_000_000 ns     The dashes _ in e.g. 1_800_000_000_000 are only used for better readability in this documentation.\n  ","date":1557010800,"expirydate":-62135596800,"kind":"section","lang":"en","lastmod":1557010800,"objectID":"2ca6385333935d934f7fedd14cf2c1c6","permalink":"https://www.eclipse.org/mosaic/docs/mosaic_configuration/","publishdate":"2019-05-05T00:00:00+01:00","relpermalink":"/mosaic/docs/mosaic_configuration/","section":"docs","summary":"On the following pages we provide a complete documentation of configuration files:\n   Configuration File Documentation     scenario_config.json  Scenario Configuration     mapping/mapping_config.","tags":null,"title":"Eclipse MOSAIC Configuration Files","type":"docs"},{"authors":null,"categories":null,"content":"Download Eclipse MOSAIC from DCAITI mirror   Download the eclipse-mosaic-20.0.zip bundle from the mirror above. Extract the package to an arbitrary path. This installation path is referenced as \u0026lt;mosaic-root\u0026gt; throughout the entire document. Install additional software required by the simulation (see below), e.g. Eclipse SUMO    Folder Content └─ \u0026lt;mosaic-root\u0026gt; ├─ etc | ├─ hosts.json .................. Configuration of the execution host, e.g. temporary directory. | ├─ logback.xml ................. Configuration of log files and levels. | └─ runtime.json ................ Configuration of all Ambassadors and Federates coupled with the MOSAIC ├─ lib ............................. Directory with all Java compiled libraries required for MOSAIC. ├─ logs ............................ Directory with log files. ├─ scenarios ....................... Directory containing all simulation scenarios. ├─ tools ........................... Additional tools, like the HTML Visualizer. ├─ CONTRIBUTING.md ├─ LICENSE ├─ mosaic.bat ...................... Start script for Windows systems. └─ mosaic.sh ....................... Start script for GNU/Linux systems.  Additional Software Each simulation with Eclipse MOSAIC requires additional software. As MOSAIC is written in JAVA, first of all, a JAVA runtime environment (JRE) needs to be installed for your operating system. Furthermore, each simulation requires additional simulators to be installed, for example the traffic simulation tool Eclipse SUMO or the communication simulators OMNeT++ / INET or ns-3.\nThe following table gives an overview of supported environments and simulators. Please make sure that you install those versions only.\n   Component Required  Version       Java   yes 7 and below not supported 8  supported 11 and above  limited supported           Eclipse SUMO   yes* 0.32.0 and below not supported 1.0.1 - 1.8.0  supported above 1.8.0  not tested    OMNeT++   optional below 5.5 not supported 5.5  supported 5.6 and above  not supported    INET   optional below 4.1 not supported 4.1  supported 4.2 and above  not supported    ns-3   optional below 3.28 not supported 3.28  supported above 3.28  not tested    * All provided scenarios require SUMO to be installed. However, if a different traffic or vehicle simulator is coupled, SUMO is not certainly required.\nUpdate Eclipse MOSAIC In order to update Eclipse MOSAIC to a new version, please perform the following steps manually:\n Backup your personal simulation scenarios from MOSAIC\u0026rsquo;s scenarios directory. Remove your old MOSAIC installation completely. Install MOSAIC by extracting the current binary archive from above. Copy your simulation scenarios back to MOSAIC\u0026rsquo;s scenarios directory. Take care of possible updates of the used software and simulators from third party (see the Compatibility Matrix above).  ","date":1557010800,"expirydate":-62135596800,"kind":"section","lang":"en","lastmod":1557010800,"objectID":"0d7696d24c78e212b3f7477df55bfbb6","permalink":"https://www.eclipse.org/mosaic/docs/getting_started/","publishdate":"2019-05-05T00:00:00+01:00","relpermalink":"/mosaic/docs/getting_started/","section":"docs","summary":"Download Eclipse MOSAIC from DCAITI mirror   Download the eclipse-mosaic-20.0.zip bundle from the mirror above. Extract the package to an arbitrary path. This installation path is referenced as \u0026lt;mosaic-root\u0026gt; throughout the entire document.","tags":null,"title":"Download Eclipse MOSAIC","type":"docs"},{"authors":null,"categories":null,"content":"The runtime infrastructure of Eclipse MOSAIC couples different simulators and can\u0026rsquo;t be run alone and, therefore, it requires pre-installed simulators. Each simulator coupled with the RTI of MOSAIC usually covers a specific domain (e.g. traffic, communication, application, electricity, or other).\nEach of the simulators must implement an interface, the so-called Ambassador. The ambassador communicates with the actual simulator, which is represented by the Federate. For some cases, if the simulator is directly coupled with the RTI (e.g. Application, or cell), the ambassador also represents the federate. This architecture allows a simple coupling of own simulators.\n#mermaid-1603209753374{font-family:\"trebuchet ms\",verdana,arial;font-size:16px;fill:#333;}#mermaid-1603209753374 .error-icon{fill:#552222;}#mermaid-1603209753374 .error-text{fill:#552222;stroke:#552222;}#mermaid-1603209753374 .edge-thickness-normal{stroke-width:2px;}#mermaid-1603209753374 .edge-thickness-thick{stroke-width:3.5px;}#mermaid-1603209753374 .edge-pattern-solid{stroke-dasharray:0;}#mermaid-1603209753374 .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-1603209753374 .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-1603209753374 .marker{fill:#333333;}#mermaid-1603209753374 .marker.cross{stroke:#333333;}#mermaid-1603209753374 svg{font-family:\"trebuchet ms\",verdana,arial;font-size:16px;}#mermaid-1603209753374 .label{font-family:\"trebuchet ms\",verdana,arial;color:#333;}#mermaid-1603209753374 .label text{fill:#333;}#mermaid-1603209753374 .node rect,#mermaid-1603209753374 .node circle,#mermaid-1603209753374 .node ellipse,#mermaid-1603209753374 .node polygon,#mermaid-1603209753374 .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-1603209753374 .node .label{text-align:center;}#mermaid-1603209753374 .node.clickable{cursor:pointer;}#mermaid-1603209753374 .arrowheadPath{fill:#333333;}#mermaid-1603209753374 .edgePath .path{stroke:#333333;stroke-width:1.5px;}#mermaid-1603209753374 .flowchart-link{stroke:#333333;fill:none;}#mermaid-1603209753374 .edgeLabel{background-color:#e8e8e8;text-align:center;}#mermaid-1603209753374 .edgeLabel rect{opacity:0.5;background-color:#e8e8e8;fill:#e8e8e8;}#mermaid-1603209753374 .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-1603209753374 .cluster text{fill:#333;}#mermaid-1603209753374 div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:\"trebuchet ms\",verdana,arial;font-size:12px;background:hsl(80,100%,96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-1603209753374:root{--mermaid-font-family:\"trebuchet ms\",verdana,arial;}#mermaid-1603209753374 flowchart{fill:apa;}TraCIProtobufEclipse MOSAIC RTIEclipse SUMOOMNeT++ApplicationAmbassadorSumoAmbassadorOmnetppAmbassador   The following simulators are coupled already with MOSAIC:\n table th:first-of-type { width: 26%; }     Domain Simulator Name Description     Application Simulation  MOSAIC Application   Application prototyping and simulation.        Traffic / Vehicle Simulation  Eclipse SUMO   Microscopic Traffic simulation.    PHABMACS Sub-microscopic vehicle simulation with 3D visualization. Documentation will be published soon.        Network / Communication Simulation  OMNeT++   Event-based network simulator for ITS-G5 and cellular communication.     ns-3   Event-based network simulator for ITS-G5 and cellular communication.     MOSAIC Simple Network Simulator   Simulator for ITS-G5 ad-hoc communication using simplified models.     MOSAIC Cell   Simulator for cellular communication.        Environment Simulation  MOSAIC Environment   Environmental event simulation.        E-Mobility Simulation  MOSAIC Battery   Electric vehicle simulation.    ","date":1557010800,"expirydate":-62135596800,"kind":"section","lang":"en","lastmod":1557010800,"objectID":"7998013f795ff6ddbb68d3d1e213effe","permalink":"https://www.eclipse.org/mosaic/docs/simulators/","publishdate":"2019-05-05T00:00:00+01:00","relpermalink":"/mosaic/docs/simulators/","section":"docs","summary":"The runtime infrastructure of Eclipse MOSAIC couples different simulators and can\u0026rsquo;t be run alone and, therefore, it requires pre-installed simulators. Each simulator coupled with the RTI of MOSAIC usually covers a specific domain (e.","tags":null,"title":"Simulators Overview","type":"docs"},{"authors":null,"categories":null,"content":"This section provides information on creating own simulation scenarios. A scenario is generally a folder structure that reflects the different components usually found in a simulation. Each of the folders contains various configuration files which in total describe the simulation setup, including the movements of the vehicles, the definition of the road network, communication properties, and the like.\nThe following file structure shows the minimum setup of a typical simulation scenario in Eclipse MOSAIC:\n└─ \u0026lt;scenarioName\u0026gt; ├─ application | └─ \u0026lt;scenarioName\u0026gt;.db................ Scenario database file ├─ mapping | └─ mapping_config.json ............. Mapping configuration file ├─ sumo | └─ \u0026lt;scenarioName\u0026gt;.net.xml .......... SUMO network file | └─ \u0026lt;scenarioName\u0026gt;.sumocfg .......... SUMO configuration file └─ scenario_config.json ............... Basic configuration of the simulation scenario  In addition to those files, each simulator need to be provided with their custom configuration files.\nMain Configuration The main configuration file of a scenario is scenario_config.json. In this file basic properties are configured, such as the name of the scenario, the random seed, and activated simulators. Such a file looks like the following:\n{ \u0026quot;simulation\u0026quot;: { \u0026quot;id\u0026quot;: \u0026quot;Barnim\u0026quot;, \u0026quot;duration\u0026quot;: \u0026quot;1000s\u0026quot;, \u0026quot;randomSeed\u0026quot;: 268965854, \u0026quot;projection\u0026quot;: { \u0026quot;centerCoordinates\u0026quot;: { \u0026quot;latitude\u0026quot;: 52.511289, \u0026quot;longitude\u0026quot;: 13.3167457 }, \u0026quot;cartesianOffset\u0026quot;: { \u0026quot;x\u0026quot;: -385769.05, \u0026quot;y\u0026quot;: -5819239.29 } }, \u0026quot;network\u0026quot;: { \u0026quot;netMask\u0026quot;: \u0026quot;255.255.0.0\u0026quot;, \u0026quot;vehicleNet\u0026quot;: \u0026quot;10.1.0.0\u0026quot;, \u0026quot;rsuNet\u0026quot;: \u0026quot;10.2.0.0\u0026quot;, \u0026quot;tlNet\u0026quot;: \u0026quot;10.3.0.0\u0026quot;, \u0026quot;csNet\u0026quot;: \u0026quot;10.4.0.0\u0026quot;, \u0026quot;serverNet\u0026quot;: \u0026quot;10.5.0.0\u0026quot;, \u0026quot;tmcNet\u0026quot;: \u0026quot;10.6.0.0\u0026quot; } }, \u0026quot;federates\u0026quot;: { \u0026quot;application\u0026quot;: true, \u0026quot;environment\u0026quot;: false, \u0026quot;cell\u0026quot;: false, \u0026quot;ns3\u0026quot;: false, \u0026quot;omnetpp\u0026quot;: false, \u0026quot;sns\u0026quot;: false, \u0026quot;sumo\u0026quot;: true, \u0026quot;visualizer\u0026quot;: true } }  The following fields needs to be configured:\n id - The name of the scenario duration - The duration of the simulation in seconds. randomSeed - The seed to initialze the random number generator with in order to have deterministic results. If not set, a random seed is taken. projection - Configures the coordinate transformation from geographic coordinates to cartesian coordinates. Having a correct setting here is crucial to get correct results that map to real world coordinates so the simulation results can be visualized in some way. The center coordinate will be used to determine the correct UTM zone, the cartesianOffset can be determined by having a look at the trafﬁc simulators network ﬁle, e.g. SUMOs *.net.xml contains this information in the netOffset attribute of the location tag. network - Within this config the address resolution scheme is speciﬁed. The subnets for all unit types are described here. Usually, default configuration should be sufficient. However, if you have many vehicles in your scenario the IP address space would be to small to provide enough addresses. In such cases, the netMask and all subnets have to be configured accordingly. Last but not least, the federate tags define which simulators are active in the simulation.  Traffic Simulator Configuration The generated files for the used traffic simulator are placed into the folder named after that simulator, e. g. sumo . For example, the \u0026lt;scenarioName\u0026gt;.sumocfg describes the main configuration of the SUMO simulator, which should refer to a network file and a route file:\n\u0026lt;configuration\u0026gt; \u0026lt;input\u0026gt; \u0026lt;net-file value=\u0026quot;MyScenario.net.xml\u0026quot; /\u0026gt; \u0026lt;route-files value=\u0026quot;MyScenario.rou.xml\u0026quot; /\u0026gt; \u0026lt;/input\u0026gt; \u0026lt;/configuration\u0026gt;  While the *.net.xml is a mandatory file to be placed within the sumo directory, the *.rou.xml is automatically generated by the SumoAmbassador when the simulation is started. More information about the configuration of SUMO can be found here  .\nApplications and Mapping  Read the detailed documentation of the Mapping Configuration.\n  Vehicles Usually you want the simulated vehicles to be equipped with some kind of applications that influence the vehicle\u0026rsquo;s behavior. To do that you copy the jar files of your applications to the folder \u0026lt;scenarioName\u0026gt;/application . Having the applications in place you will have to create a mapping_config.json file in the folder \u0026lt;scenarioName\u0026gt;/mapping .\nThe following file would spawn 1 vehicle every five seconds (720 veh/hour divided by 3600 sec) until it reaches the max number of vehicles: 500. All the vehicles would be equipped with an application sending CA-messages periodically.\n{ \u0026quot;prototypes\u0026quot;:[ { \u0026quot;name\u0026quot;: \u0026quot;Car\u0026quot;, \u0026quot;accel\u0026quot;: 2.6, \u0026quot;decel\u0026quot;: 4.5, \u0026quot;maxSpeed\u0026quot;: 80.0, \u0026quot;applications\u0026quot;: [ \u0026quot;org.eclipse.mosaic.fed.application.app.etsi.VehicleCamSendingApp\u0026quot; ] } ], \u0026quot;vehicles\u0026quot;:[ { \u0026quot;startingTime\u0026quot;: 0.0, \u0026quot;targetFlow\u0026quot;: 720, \u0026quot;maxNumberVehicles\u0026quot;: 500, \u0026quot;route\u0026quot;: \u0026quot;3\u0026quot;, \u0026quot;types\u0026quot;: [ { \u0026quot;name\u0026quot;: \u0026quot;Car\u0026quot; } ] } ] }  Traffic lights If you want to simulate traffic lights equipped with applications, traffic lights should be defined in the simulator specific configuration file and also added to the mapping configuration file. The applications can be equipped by explicitly specifying them as \u0026ldquo;applications\u0026rdquo;\n{ \u0026quot;trafficLights\u0026quot;: [ { \u0026quot;tlGroupId\u0026quot;: \u0026quot;Bismarkstr_Krummestr\u0026quot;, \u0026quot;applications\u0026quot;: [ \u0026quot;org.eclipse.mosaic.app.tutorial.TrafficLightApp\u0026quot; ] } ] }  or by referring to previously defined prototypes:\n{ \u0026quot;prototypes\u0026quot;:[ { \u0026quot;name\u0026quot;: \u0026quot;Car\u0026quot;, \u0026quot;accel\u0026quot;: 2.6, \u0026quot;decel\u0026quot;: 4.5, \u0026quot;maxSpeed\u0026quot;: 80.0, \u0026quot;applications\u0026quot;: [ \u0026quot;org.eclipse.mosaic.fed.application.app.etsi.VehicleCamSendingApp\u0026quot; ] }, { \u0026quot;name\u0026quot;: \u0026quot;TrafficLight\u0026quot;, \u0026quot;applications\u0026quot;: [ \u0026quot;org.eclipse.mosaic.app.tutorial.TrafficLightApp\u0026quot; ] } ], \u0026quot;vehicles\u0026quot;:[ { \u0026quot;startingTime\u0026quot;: 0.0, \u0026quot;targetFlow\u0026quot;: 720, \u0026quot;maxNumberVehicles\u0026quot;: 500, \u0026quot;route\u0026quot;: \u0026quot;3\u0026quot;, \u0026quot;types\u0026quot;: [ { \u0026quot;name\u0026quot;: \u0026quot;Car\u0026quot; } ] } ], \u0026quot;trafficLights\u0026quot;: [ { \u0026quot;tlGroupId\u0026quot;: \u0026quot;Bismarkstr_Krummestr\u0026quot;, \u0026quot;name\u0026quot;: \u0026quot;TrafficLight\u0026quot; } ] }  Please note that traffic light name and traffic light itself in the mapping file stand for a traffic light group controlling a whole junction. Traffic light group can consist of many individual traffic lights controlling an exact lane. The value of the \u0026ldquo;tlGroupId\u0026rdquo; key MUST coincide with the name of the traffic light group in the traffic simulator related configuration file (with tlLogic id for SUMO and with junction id for Phabmacs).\nFor SUMO, the description of traffic light groups and their programs can be found in \u0026lt;scenarioname\u0026gt;.net.xml:\n\u0026lt;tlLogic id=\u0026quot;26704448\u0026quot; type=\u0026quot;static\u0026quot; programID=\u0026quot;1\u0026quot; offset=\u0026quot;0\u0026quot;\u0026gt; \u0026lt;phase duration=\u0026quot;39\u0026quot; state=\u0026quot;GGrG\u0026quot;/\u0026gt; \u0026lt;phase duration=\u0026quot;6\u0026quot; state=\u0026quot;yyry\u0026quot;/\u0026gt; \u0026lt;phase duration=\u0026quot;39\u0026quot; state=\u0026quot;rrGG\u0026quot;/\u0026gt; \u0026lt;phase duration=\u0026quot;6\u0026quot; state=\u0026quot;rryy\u0026quot;/\u0026gt; \u0026lt;/tlLogic\u0026gt;  Corresponding mapping_config.json:\n{ ... \u0026quot;trafficLights\u0026quot;: [ { \u0026quot;tlGroupId\u0026quot;: \u0026quot;26704448\u0026quot;, \u0026quot;name\u0026quot;: \u0026quot;TrafficLight\u0026quot; } ] }  More information on the mapping configuration can be found ( here  .\nFor more information about how SUMO traffic lights work please refer to SUMO Traffic Lights  .\nThe application folder furthermore needs a generated database file \u0026lt;scenarioName\u0026gt;.db . This database file contains information about the road network (road topology) and all routes the vehicles can drive on. This file is usually generated by the tool scenario-convert, which is described here  in detail.\nCommunication Simulator The configuration of the communication parameters are usually not dependent from the location of the road network. Therefore, most of the required files can be extracted from other scenarios, such Barnim  or Tiergarten  . Depending on the simulator you will need to configure the geographic extend of the simulation area. You can ﬁnd that data in the trafﬁc simulators network file, e.g. SUMOs *.net.xml contains this information in the convBoundary attribute of the location tag.\n For OMNeT++, it concerns the values of constraintArea in the omnetpp.ini For the Eclipse MOSAIC Cell simulator, the expansions do not need to be conﬁgured directly. However, the areas of the conﬁgured regions (in regions.json) have to be in line with the scenario location. The SNS also comes without an additional expansion deﬁnition.  Further information on the communication simulators can be found in: Eclipse MOSAIC SNS  Eclipse MOSAIC Cell  OMNeT++  ns-3  ","date":1557010800,"expirydate":-62135596800,"kind":"section","lang":"en","lastmod":1557010800,"objectID":"911d7d211da284d47641d647331b899d","permalink":"https://www.eclipse.org/mosaic/docs/building_scenarios/","publishdate":"2019-05-05T00:00:00+01:00","relpermalink":"/mosaic/docs/building_scenarios/","section":"docs","summary":"This section provides information on creating own simulation scenarios. A scenario is generally a folder structure that reflects the different components usually found in a simulation. Each of the folders contains various configuration files which in total describe the simulation setup, including the movements of the vehicles, the definition of the road network, communication properties, and the like.","tags":null,"title":"Simulation Scenarios","type":"docs"},{"authors":null,"categories":null,"content":"To get a simple and instant impression of a simulation or to get an idea of how fast it runs or where a simulation is located, the WebSocket Visualizer was created. It runs in the browser and shows an OpenLayers Map with markers, indicating the positions of all vehicles, as well as overall the simulation progresses.\n Red vehicles are sending messages and green vehicles are receiving messages at that specific point of time in the simulation.   To start the visualization, simply open the tools/web/visualizer.html in your browser. As soon as the page has finished loading all of its content, it starts trying to connect to the WebSocket created by the Eclipse MOSAIC simulation. The WebSocket is also enabled by default for the tutorial scenario Barnim. For more details see the file Barnim/output/output_config.xml.\n\u0026lt;?xml version=\u0026quot;1.0\u0026quot; encoding=\u0026quot;UTF-8\u0026quot;?\u0026gt; \u0026lt;configuration\u0026gt; \u0026lt;output id=\u0026quot;websocket\u0026quot; enabled=\u0026quot;true\u0026quot; loader=\u0026quot;org.eclipse.mosaic.fed.output.generator.websocket.WebsocketVisualizerLoader\u0026quot;\u0026gt; \u0026lt;synchronized\u0026gt;true\u0026lt;/synchronized\u0026gt; \u0026lt;port\u0026gt;46587\u0026lt;/port\u0026gt; \u0026lt;subscriptions\u0026gt; \u0026lt;subscription id=\u0026quot;VehicleUpdates\u0026quot; enabled=\u0026quot;true\u0026quot;/\u0026gt; \u0026lt;subscription id=\u0026quot;V2xMessageReception\u0026quot; enabled=\u0026quot;true\u0026quot;/\u0026gt; \u0026lt;subscription id=\u0026quot;V2xMessageTransmission\u0026quot; enabled=\u0026quot;true\u0026quot;/\u0026gt; \u0026lt;subscription id=\u0026quot;VehicleRegistration\u0026quot; enabled=\u0026quot;true\u0026quot;/\u0026gt; \u0026lt;subscription id=\u0026quot;RsuRegistration\u0026quot; enabled=\u0026quot;true\u0026quot;/\u0026gt; \u0026lt;subscription id=\u0026quot;TrafficLightRegistration\u0026quot; enabled=\u0026quot;true\u0026quot;/\u0026gt; \u0026lt;/subscriptions\u0026gt; \u0026lt;/output\u0026gt; \u0026lt;/configuration\u0026gt;  As soon, as the simulation is running, you should see vehicle markers moving around and indicating if they are sending V2X messages (green) or receiving V2X message (red).\nThe status bar at the bottom of the page indicates the current connection/simulation state. There are four possible states:\n Connecting - Trying to connect to the WebSocket opened by Eclipse MOSAIC. Simulating - Periodically fetching simulation data and updating markers accordingly. Simulation finished - The simulation has finished. Error - An error occurred. Either there was a problem caused by the WebSocket itself, or a timeout occurred while trying to connect to the WebSocket.  After the simulation has finished, you can click on the reconnect button and then run the simulation again. You can also start the visualization at each simulation run, using the command line parameter -v. In that case, Eclipse MOSAIC will automatically open the tools/web/visualizer.html in your default browser once the simulation starts.\n By default, the WebSocket Visualizer does not work on Microsoft Edge. UWP (UniversalWindows Platform) apps onWindows 10 do not have direct network access but are subject to a network isolation for security reasons, preventing localhost loopback by default. WhileMicrosoft Edge itself does allow localhost access, it treats localhost as an Internet site, which leads to restrictions e.g. for IPC over IP. To prevent this, an exception for Edgemust be added to the network isolation via the following command in an elevated command prompt:\nCheckNetIsolation LoopbackExempt -a -n=\u0026quot;Microsoft.MicrosoftEdge_8wekyb3d8bbwe\u0026quot;    ","date":1557010800,"expirydate":-62135596800,"kind":"section","lang":"en","lastmod":1557010800,"objectID":"4ceda5b87ab93856c1c3520fdb9ecfb3","permalink":"https://www.eclipse.org/mosaic/docs/visualization/","publishdate":"2019-05-05T00:00:00+01:00","relpermalink":"/mosaic/docs/visualization/","section":"docs","summary":"To get a simple and instant impression of a simulation or to get an idea of how fast it runs or where a simulation is located, the WebSocket Visualizer was created.","tags":null,"title":"WebSocket Visualizer","type":"docs"},{"authors":null,"categories":null,"content":" You can use a Readable Unit anywhere where you have the option of:\n number or string integer or string     📃 Corresponding configuration file: scenario_config.json\n \nScenario Schema describing the JSON file structure for the main scenario configuration.\nProperties\n    Type Description Required Boundaries Default     simulation  simulation   Basic properties of the simulation scenario. ✓ Yes None None   federates object Defines the list of ambassadors/simulators which are used by the simulation. For each simulator (referenced by its id) a boolean value must be given, which enables or disables the simulator. ✓ Yes None None    Further property restrictions:\n\nScenario.federates  Type of each property: boolean   \nsimulation Basic properties of the simulation scenario.\nProperties\n    Type Description Required Boundaries Default     id string The id or name of the simulation scenario. ✓ Yes None None   duration string\nnumber The duration of the simulation. If defined as a number, then the unit to be applied is ns. Alternatively this can be defined as a string to include the unit of measurement (e.g. \u0026lsquo;300 s\u0026rsquo;) ✓ Yes None None   randomSeed integer The random seed to apply. This influences the application mapping, the communication models, and any use of randomness inside of applications. If not set, the random number generator will be initialized without a seed resulting in different results for each run. Note that several other simulators (e.g. SUMO) come with their own random number generators which are not affected by this property. No None None   projection  projection   Configures the projection used to transform geographical coordinates (WGS84) to local cartesian coordinates used by various simulators (e.g. SUMO, or OMNeT++). The projection is based on UTM and must be adapted to the used traffic network. ✓ Yes None None   network  network   Defines the subnets (e.g. 10.0.0.0) used for generating IP addresses for each unit in the simulation. Each type of unit is configured with its own subnet. A default configuration is used, when left out from the configuration. No None default network     \nProjection Configures the projection used to transform geographical coordinates (WGS84) to local cartesian coordinates used by various simulators (e.g. SUMO, or OMNeT++). The projection is based on UTM and must be adapted to the used traffic network.\nProperties\n    Type Description Required Boundaries Default     centerCoordinates  geoPoint   Geographic coordinates of the rough center of the map / playground used in this scenario. This is just used to determine the UTM zone used for any further projection. ✓ Yes None None   cartesianOffset  cartesianOffset   A cartesian offset which is added to the UTM transformation. In most cases, this must be the exact offset which can be found in the location.netOffset of the *.net.xml of the scenario. ✓ Yes None None     \nGeoPoint Geographic coordinates of the rough center of the map / playground used in this scenario. This is just used to determine the UTM zone used for any further projection.\nProperties\n    Type Description Required Boundaries Default     longitude number East-west position of a point on earth. ✓ Yes [-180, 180] None   latitude number North-south position of a point on earth. ✓ Yes [-90, 90] None     \nCartesianOffset A cartesian offset which is added to the UTM transformation. In most cases, this must be the exact offset which can be found in the location.netOffset of the *.net.xml of the scenario.\nProperties\n    Type Description Required Boundaries Default     x number The value to add to the X coordinate after UTM transformation ✓ Yes None None   y number The value to add to the Y coordinate after UTM transformation ✓ Yes None None     \nNetwork Addressing Defines the subnets (e.g. 10.0.0.0) used for generating IP addresses for each unit in the simulation. Each type of unit is configured with its own subnet. A default configuration is used, when left out from the configuration.\nProperties\n    Type Description Required Boundaries Default     netMask string The net mask used for IP generation. No None 255.0.0.0   vehicleNet string The subnet used for assigning IPs to vehicles. No None 10.0.0.0   rsuNet string The subnet used for assigning IPs to road side units. No None 11.0.0.0   tlNet string The subnet used for assigning IPs to traffic lights. No None 12.0.0.0   csNet string The subnet used for assigning IPs to charging stations. No None 13.0.0.0   serverNet string The subnet used for assigning IPs to servers. No None 14.0.0.0   tmcNet string The subnet used for assigning IPs to traffic management centers. No None 15.0.0.0    ","date":-62135596800,"expirydate":-62135596800,"kind":"section","lang":"en","lastmod":-62135596800,"objectID":"9506d76d554845371af09c7ff262d688","permalink":"https://www.eclipse.org/mosaic/docs/mosaic_configuration/scenario_config/","publishdate":"0001-01-01T00:00:00Z","relpermalink":"/mosaic/docs/mosaic_configuration/scenario_config/","section":"docs","summary":"You can use a Readable Unit anywhere where you have the option of:\n number or string integer or string     📃 Corresponding configuration file: scenario_config.json","tags":null,"title":"Scenario Configuration","type":"docs"},{"authors":null,"categories":null,"content":" You can use a Readable Unit anywhere where you have the option of:\n number or string integer or string     📃 Corresponding configuration file: mapping/mapping_config.json\n \nMapping This schema describes the JSON file structure for the mapping configuration, which is used to define simulation entities.\nProperties\n    Type Description Required Boundaries Default     config  config   Object to define additional configuration options for the mapping No None None   prototypes  prototype[]   Array of prototypes, which can complete the definitions of other objects. This can be used to re-use certain configurations. All possible properties of objects are available. Only the ones needed will be used (for example an RSU does not have a length, so this property would be ignored). No None None   typeDistributions  typeDistribution   Object to define the distribution of prototypes to reuse in vehicle spawners. A typeDistribution is referenced by it\u0026rsquo;s attribute name, which can be set to any valid string. No None None   vehicles  vehicle[]   Array of vehicles to be spawned in the simulation. This property describes the vehicles populatingthe simulation. It is possible to create a single vehicle (maxNumberVehicles should be \u0026lsquo;1\u0026rsquo; in that case) or a streamof one or multiple vehicles. The type(s) are defined in the field types. When more than one type is defined theweights in the prototype can be used to balance them against each other. No None None   matrixMappers  matrixMapper[]   Array of items to define additional traffic that will be spawned using OD-matrices. No None None   rsus  rsu[]   Array of Road Side Units (RSUs). For RSUs only applications can be defined along with the position. No None None   servers  server[]   Array of servers. Servers are a form of units that have no geographical location. The network properties of a server can be defined in the network.json-configuration in the cell-module. No None None   tmcs  tmc[]   Array of Traffic Management Centers (TMCs). TMCs are specialized forms of servers having direct access to data collected by induction loops and lane area detectors. The network properties of a TMC can be defined in the network.json-configuration in the cell-module. No None None   trafficLights  trafficLights[]   Array of prototypes for traffic lights. Since it is a traffic light only applications can be defined. Traffic light prototypes can be distributed among all traffic lights of an application by weight or assigned to specific traffic lights by using the ID of traffic light groups as reference. No None None   chargingStations  chargingStation[]   Array of electric vehicle charging stations based on ETSI TS 101 556-1. An infrastructure which provides one or several electric vehicle charging spots to supply electric energy for charging electric vehicles. No None None    Further property restrictions:\n\nMapping.typeDistributions  Type of each property: array   \nconfig Object to define additional configuration options for the mapping\nProperties\n    Type Description Required Boundaries Default     start number Defines the point in time (in seconds) to start spawning vehicles. If not set (default), all vehicles will be spawned according to the vehicles configuration. No [0, +$\\infty$] None   end number Defines the point in time (in seconds) to end spawning vehicles. If not set (default), all vehicles will be spawned according to the vehicles configuration or until the simulation ends. No [0, +$\\infty$] None   scaleTraffic number Scales the traffic by the given factor. E.g. 2.0 would double the number of spawned vehicles No [0, +$\\infty$] 1   adjustStartingTimes boolean If set to true and if the parameter start is set, the starting times of each spawner is adjusted accordingly, so that we shouldn\u0026rsquo;t wait in case that the simulation starting time and spawner starting time are widely spread out. All spawners before start will be completely ignored then. No None false   randomizeFlows boolean If set to true, all flow definitions defined by vehicle spawners with more than one vehicle resulting in slightly randomized departure times. The specified targetFlow of the vehicle spawner is kept. No None false   randomizeStartingTimes boolean If set to true, the starting times of all vehicle spawner definitions are randomized by +-60seconds. No None false   randomizeWeights boolean If set to true, the configured weights of all types are slightly randomized by +-1% of the sum of all weights. No None false     \nprototype Object to define a prototype, which can complete the definitions of other objects. This can be used to re-use certain configurations. All possible properties of objects are available. Only the ones needed will be used (for example an RSU does not have a length, so this property would be ignored).\nProperties\n    Type Description Required Boundaries Default     name string The name of this prototype is used to match it against other objects. ✓ Yes None None   group string The group name is used for (statistical) evaluation purposes with the StatisticOutput and ITEF. It allows to summarize multiple prototype entities. No None None   accel number Acceleration in m/s^2. No (0, +$\\infty$] None   decel number Deceleration in m/s^2. No (0, +$\\infty$] None   length string\nnumber Length of the vehicle. If defined as a number, then the default unit is m. Alternatively this can be defined as a string to specify the unit of measurement (e.g. \u0026lsquo;500 cm\u0026rsquo;). No (0, +$\\infty$] None   maxSpeed string\nnumber Maximal speed. If defined as a number, then the default unit is m/s. Alternatively this can be defined as a string to include the unit of measurement (e.g. \u0026lsquo;50 kmh\u0026rsquo;). No (0, +$\\infty$] None   minGap string\nnumber Distance in meter between front bumper of a vehicle and the back bumper of its leader in a traffic jam. If defined as a number, then the default unit is m. Alternatively this can be defined as a string to include the unit of measurement (e.g. \u0026lsquo;300 cm\u0026rsquo;). No (0, +$\\infty$] None   sigma number Driver imperfection. This is a parameter of the car-following model. No [0, 1] None   tau number Driver reaction time in seconds. This is a parameter of the car-following model. No [0, +$\\infty$] None   weight number The weight is used to distribute objects between multiple types. All weights do NOT have to add up to 1 or 100. (Example: A vehicle spawner defining a traffic stream contains two prototypeDeserializers with the weights being 4 and 6. The resulting traffic stream will consist to 40% of the one type and 60% of the other) No [0, +$\\infty$] None   vehicleClass string Class of the vehicle. The classes are used in lane definitions and allow/disallow the use of lanes for certain vehicle types (e.g. a taxi lane). No Enum    None   applications string[] The applications to be used for this object. No None None    Further property restrictions:\n\nprototype.vehicleClass  Allowed values:  Unknown Car LightGoodsVehicle HeavyGoodsVehicle PublicTransportVehicle EmergencyVehicle WorksVehicle ExceptionalSizeVehicle VehicleWithTrailer HighSideVehicle MiniBus Taxi ElectricVehicle AutomatedVehicle Bicycle Motorcycle HighOccupancyVehicle     \ntypeDistribution Object to define the distribution of prototypes to reuse in vehicle spawners. A typeDistribution is referenced by it\u0026rsquo;s attribute name, which can be set to any valid string.\nThe following additional properties are allowed:\n array[ prototype  ]   \nvehicle Object to define vehicles to be spawned in the simulation. This property describes the vehicles populating the simulation. It is possible to create a single vehicle (maxNumberVehicles should be \u0026lsquo;1\u0026rsquo; in that case) or a stream of one or multiple vehicles. The types (or type) are defined in the field types. When more than one type is defined the weights in the prototype can be used to balance them against each other.\nProperties\n    Type Description Required Boundaries Default     startingTime number Time at which the first vehicle will be created. No [0, +$\\infty$] 0   maxTime number Simulation time in seconds at which no more vehicles will be created. No [0, +$\\infty$] None   targetFlow number Density of vehicles per hour. Vehicles will be spawned uniformly. No [0, +$\\infty$] 600   maxNumberVehicles number Maximum number of vehicles to be created from this source. No [0, +$\\infty$] None   departSpeed string\nnumber The speed at which the vehicle is supposed to depart. If defined as a number, then the default unit is m/s. Alternatively this can be defined as a string to include the unit of measurement (e.g. \u0026lsquo;10 kmh\u0026rsquo;). Depending on the simulator this value may only be used if departSpeedMode is set to PRECISE. No None None   departSpeedMode string The depart speed mode determines the vehicle\u0026rsquo;s speed at insertion. No Enum    MAXIMUM   laneSelectionMode string The lane selection mode chooses the lane for the next departing vehicle. No Enum    DEFAULT   spawningMode string Adjusts the departure time of individual vehicles. No Enum    CONSTANT   deterministic boolean Determines if selection of a vehicles type when spawning follows a deterministic or stochastic model. When set to true the spawning-process will choose exactly the same types with every execution. When set to false the order of types may be different and selected weights will be reached more slowly. No None true   pos number Position within the route where the vehicle(s) should be spawned. No [0, +$\\infty$] 0   route string Route that the vehicle(s) should use. If an origin and a destination are specified this route will be treated as a preference (i.e. it will be selected if it connects the two points in question). No None None   lanes number[] Array of numbers to define the lanes to be used. The vehicles will be evenly distributed among the given lanes. When no value is given lane zero will be used for all vehicles. No None None   types  prototype[1-*]   List of possible vehicle types to be spawned. In this list you can simply refer to an existing prototype by its name attribute to include everything defined there. You can also overwrite every attribute of the prototype. If you don\u0026rsquo;t have an existing prototype the definitions found here will be used as the prototype definition itself. No None None   typeDistribution string Identifier of the typeDistribution which defines the distribution of vehicle types. No None None   destination  geoCircle   Object to define an immutable pair of a geoPoint center position and a radius in meters. ✓ Yes None None   origin  geoCircle   Object to define an immutable pair of a geoPoint center position and a radius in meters. ✓ Yes None None    Further property restrictions:\n\nvehicle.departSpeedMode  Allowed values:  PRECISE RANDOM MAXIMUM     vehicle.laneSelectionMode  Allowed values:  DEFAULT ROUNDROBIN ROUNDROBIN_HIGHWAY HIGHWAY RANDOM FREE ALLOWED BEST FIRST     vehicle.spawningMode  Allowed values:  CONSTANT GROW POISSON SHRINK GROW_AND_SHRINK GROW_EXPONENTIAL SHRINK_EXPONENTIAL GROW_AND_SHRINK_EXPONENTIAL     \ngeoCircle Object to define an immutable pair of a geoPoint center position and a radius in meters.\nProperties\n    Type Description Required Boundaries Default     center  geoPoint   Object to define geographical point coordinates. ✓ Yes None None   radius number Radius of the circle. ✓ Yes [0, +$\\infty$] None     \nGeoPoint Object to define geographical point coordinates.\nProperties\n    Type Description Required Boundaries Default     longitude number East-west position of a point on earth. ✓ Yes [-180, 180] None   latitude number North-south position of a point on earth. ✓ Yes [-$\\infty$, 90] None     \nmatrixMapper Object to define a mapper for an Origin-Destination (OD) matrix. The mapper contains a list of points (with varying radius) and a matrix (arrays) of flow values. It creates a series of conventional vehicles spawners from the specified data.\nProperties\n    Type Description Required Boundaries Default     points  odPoint[]   Array of odPoints that can be referenced from the OD-matrix. ✓ Yes None None   types  prototype[]   Array of prototypes to define the vehicles that should be spawned. No None None   deterministic boolean If deterministic is true the spawning-process will be exactly the same with every execution. If left false the order is different and the selected weights will be reached slower than in the deterministic mode. No None true   odValues array[] Values for the OD-matrix. Unit should be vehicles/hour. ✓ Yes None None     \nodPoint Object to define a point that can be referenced from an OD-matrix.\nProperties\n    Type Description Required Boundaries Default     name string The name of the point. This identifier is used to reference the odPoint. ✓ Yes None None   position  geoCircle   Object to define an immutable pair of a geoPoint center position and a radius in meters. ✓ Yes None None     \nrsu Object to define a Road Side Unit (RSU). For RSUs only applications can be defined along with the position.\nProperties\n    Type Description Required Boundaries Default     position  geoPoint   Object to define geographical point coordinates. ✓ Yes None None   name string Used to be matched with a prototype. If a prototype name matches this name, all properties not set in this object will be overwritten by those defined in the prototype. No None None   group string The group name is used for (statistical) evaluation purposes with the StatisticOutput and ITEF. It allows to summarize multiple rsu entities. No None None   applications string[] Array of strings that specifies the applications to be used for this object. If none are specified, none are used No None None     \nserver Object to define a server. Servers are a form of units that have no geographical location. The network properties of a server can be defined in the network.json-configuration in the cell-module.\nProperties\n    Type Description Required Boundaries Default     name string Used to be matched with a prototype. If a prototype name matches this name, all properties not set in this object will be overwritten by those defined in the prototype. No None None   group string The group name is used to match with configurations in the network.json-configuration in the cell-module. No None None   applications string[] The applications to be used for this object. If none are specified, none are used. No None None     \ntmc Object to define a Traffic Management Center (TMCs). TMCs are specialized forms of server directly communicating with induction loops and lane area detectors. The network properties of a TMC can be defined in the network.json-configuration in the cell-module.\nProperties\n    Type Description Required Boundaries Default     name string Used to be matched with a prototype. If a prototype name matches this name, all properties not set in this object will be overwritten by those defined in the prototype. No None None   group string The group name is used to match with configurations in the network.json-configuration in the cell-module. No None None   applications string[] The applications to be used for this object. If none are specified, none are used. No None None   inductionLoops string[] The induction loops the TMC shall be matched with. If none are specified, none are used. No None None   laneAreaDetectors string[] The lane area detectors the TMC shall be matched with. If none are specified, none are used. No None None     \ntrafficLights Object to define a prototype for a traffic light. Since it is a traffic light only applications can be defined. Traffic light prototypes can be distributed among all traffic lights of an application by weight or assigned to specific traffic lights by using the ID of traffic light groups as reference.\nProperties\n    Type Description Required Boundaries Default     name string Used to be matched with a prototype. If a prototype name matches this name, all properties not set in this object will be overwritten by those defined in the prototype. No None None   tlGroupId string The ID of a traffic light group. This property is used to map applications to specific traffic lights. No None None   group string The group name is used for (statistical) evaluation purposes with the StatisticOutput and ITEF. It allows to summarize multiple trafficLights entities. No None None   weight number The weight is used to distribute traffic lights between multiple default types. If tlGroupId is not set, then the default value is 1, otherwise 0. All weights do NOT have to add up to 1 or 100. No [0, +$\\infty$] None   applications string[] The applications to be used for this object. If none are specified, none are used No None None     \nchargingStation Object to define an electric vehicle charging station based on ETSI TS 101 556-1. An infrastructure which provides one or several electric vehicle charging spots to supply electric energy for charging electric vehicles.\nProperties\n    Type Description Required Boundaries Default     position  geoPoint   Object to define geographical point coordinates. ✓ Yes None None   operator string The EV charging station operator (e.g. energy provider) identification. ✓ Yes None None   group string The group name is used for (statistical) evaluation purposes with the StatisticOutput and ITEF. It allows to summarize multiple charginStation entities. No None None   access string Access restrictions, e.g. open to all or restricted to some communities, free of access or paying access. ✓ Yes None None   name string Used to be matched with a prototype. If a prototype name matches this name, all properties not set in this object will be overwritten by those defined in the prototype. No None None   chargingSpots  chargingSpot[]   List of the electric vehicle charging spots associated with this electric vehicle charging station. ✓ Yes None None   applications string[] The application to be used for this object. No None None     \nchargingSpot Object to define an electric vehicle charging spot based on ETSI TS 101 556-1. A set of 1 to 4 parking places arranged around a pole, where it is possible to charge an electric vehicle.\nProperties\n    Type Description Required Boundaries Default     id number Unique identifier of the charging spot. No None None   type integer The type of this electric vehicle charging spot in compliance with current standards, including IEC 62196-2. ✓ Yes [1, 3] None   parkingPlaces integer Number of available parking places, i.e. 1 to 4 parking places arranged around a pole. ✓ Yes [1, 4] None    ","date":-62135596800,"expirydate":-62135596800,"kind":"section","lang":"en","lastmod":-62135596800,"objectID":"0545c9520e50f302ba5eb1100e12a695","permalink":"https://www.eclipse.org/mosaic/docs/mosaic_configuration/mapping_ambassador_config/","publishdate":"0001-01-01T00:00:00Z","relpermalink":"/mosaic/docs/mosaic_configuration/mapping_ambassador_config/","section":"docs","summary":"You can use a Readable Unit anywhere where you have the option of:\n number or string integer or string     📃 Corresponding configuration file: mapping/mapping_config.json","tags":null,"title":"Mapping Ambassador Configuration","type":"docs"},{"authors":null,"categories":null,"content":" You can use a Readable Unit anywhere where you have the option of:\n number or string integer or string     📃 Corresponding configuration file: environment/environment_config.json\n \nEnvironment Events Schema describing the JSON file structure for the environment configuration. It is is used to define which events are evaluated by the simulator. Entities entering the areas of the events, are notified by the \u0026lsquo;EnvironmentSensorUpdates\u0026rsquo; interaction\nProperties\n    Type Description Required Boundaries Default     events  event[]   List of events. No None None     \nevent Object to define a single event configuration.\nProperties\n    Type Description Required Boundaries Default     type  eventType   Object to define the type of an event. ✓ Yes None None   location  eventLocation   Object to define the event location configuration, which is either a GeoArea (e.g. rectangle, circle, or polygon) or a specific street segment. ✓ Yes None None   time  eventTime   Object to define the temporal properties of an event. ✓ Yes None None     \neventType Object to define the type of an event.\nProperties\n    Type Description Required Boundaries Default     sensorType string Represents the type of sensor value this event is emitting (e.g. Ice, Snow, or an arbitrary Obstacle). The value can be set to any valid string. ✓ Yes None None   value integer Used for assigning a value to the event. It can be used as the strength of an event, the amount of free parking spots in a parking lot, etc. No None 1     \neventLocation Object to define the event location configuration, which is either a GeoArea (e.g. rectangle, circle, or polygon) or a specific street segment.\nProperties\n    Type Description Required Boundaries Default     area  area   Object to define the area in which the event is located in. No None None   roadSegmentId string The ID of the road segment the event is located on (Connection ID or road ID). No None None     \narea Object to define the area in which the event is located in.\nProperties\n    Type Description Required Boundaries Default     type string The type of the area. No Enum    None    Additionally ANY of the following property definitions apply:\n  geoCircle    geoRectangle    geoPolygon    Further property restrictions:\n\narea.type  Allowed values:  Rectangle Circle Polygon     \ngeoCircle Object to define an immutable pair of a geoPoint center position and a radius in meters.\nProperties\n    Type Description Required Boundaries Default     center  geoPoint   Object to define geographical point coordinates. ✓ Yes None None   radius number Radius of the circle in m. ✓ Yes [0, +$\\infty$] None     \ngeoPoint Object to define geographical point coordinates.\nProperties\n    Type Description Required Boundaries Default     longitude number East-west position of a point on earth. ✓ Yes [-180, 180] None   latitude number North-south position of a point on earth. ✓ Yes [-$\\infty$, 90] None     \ngeoRectangle Object to define an immutable pair of two different GeoPoints. Together they form a rectangular area.\nProperties\n    Type Description Required Boundaries Default     a  geoPoint   Object to define geographical point coordinates. ✓ Yes None None   b  geoPoint   Object to define geographical point coordinates. ✓ Yes None None     \ngeoPolygon Object to define a set of GeoPoints. Together the points for a polygonal area.\nProperties\n    Type Description Required Boundaries Default     vertices  geoPoint[]   Set of points representing the vertices of a polygon. No None None     \neventTime Object to define the temporal properties of an event.\nProperties\n    Type Description Required Boundaries Default     start string\nnumber Start time of the event. If defined as a number, then the default unit is ns. Alternatively this can be defined as a string to include the unit of measurement (e.g. \u0026lsquo;3 minutes\u0026rsquo;) ✓ Yes None None   end string\nnumber End time of the event. If defined as a number, then the default unit is ns. Alternatively this can be defined as a string to include the unit of measurement (e.g. \u0026lsquo;3 minutes\u0026rsquo;) ✓ Yes None None    ","date":-62135596800,"expirydate":-62135596800,"kind":"section","lang":"en","lastmod":-62135596800,"objectID":"611e7a762ba0dd0c4095ae8e1eef3bf3","permalink":"https://www.eclipse.org/mosaic/docs/mosaic_configuration/environment_config/","publishdate":"0001-01-01T00:00:00Z","relpermalink":"/mosaic/docs/mosaic_configuration/environment_config/","section":"docs","summary":"You can use a Readable Unit anywhere where you have the option of:\n number or string integer or string     📃 Corresponding configuration file: environment/environment_config.json","tags":null,"title":"Environment Configuration","type":"docs"},{"authors":null,"categories":null,"content":" You can use a Readable Unit anywhere where you have the option of:\n number or string integer or string     📃 Corresponding configuration file: sns/sns_config.json\n \nSNS Schema describing the JSON file structure for the sns configuration.\nProperties\n    Type Description Required Boundaries Default     maximumTtl integer The threshold for the amount of hops for a transmission. This is an additional, hard threshold, which can\u0026rsquo;t be exceeded. No [0, +$\\infty$] 10   singlehopRadius number Default radius in m to be used if an AdhocConfiguration doesn\u0026rsquo;t specify a radius. No None 509.4   adhocTransmissionModel  adhocTransmissionModel   Object to define an adhoc transimssion model. No None None   singlehopDelay  delay   Object to define a delay model. No None  constantDelay     singlehopTransmission  transmission   Object to define the properties of a transmission. ✓ Yes None None     \nadocTransmissionModel Object to define an adhoc transimssion model.\nProperties\n    Type Description Required Boundaries Default     type string Type of the transmission model. The simple model assumes, that all receivers can be reached even though this might not be the case in reality. No Enum    None   simpleMultihopDelay  delay   Object to define a delay model. No None  constantDelay     simpleMultihopTransmission  transmission   Object to define the properties of a transmission. ✓ Yes None None    Further property restrictions:\n\nadhocTransmissionModel.type  Allowed values:  SimpleAdhocTransmissionModel SophisticatedAdhocTransmissionModel     \ndelay Object to define a delay model.\nAdditionally ONE of the following property definitions apply:\n  gammaDelay    constantDelay    simpleRandomDelay     \ngammaDelay Object to define a model for GammaRandomDelay or GammaSpeedDelay. GammaRandomDelay bases directly on the Gamma distribution (b=2,p=2) with minimum and expected value. Due to the nature of the Gamma distribution, the resulting delays can be far higher than the expected value. GammaSpeedDelay bases on the GammaRandomDelay and includes an additional speed penalty according to the current speed of the vehicle.\nProperties\n    Type Description Required Boundaries Default     type string Type of Gamma delay. ✓ Yes Enum    None   minDelay number\nstring Minimum delay for the Gamma distribution. If defined as a number, then the default unit is ns. Alternatively this can be defined as a string to include the unit of measurement (e.g. \u0026lsquo;3 seconds\u0026rsquo;) ✓ Yes None None   expDelay number\nstring Expected delay for the Gamma distribution. If defined as a number, then the default unit is ns. Alternatively this can be defined as a string to include the unit of measurement (e.g. \u0026lsquo;3 seconds\u0026rsquo;) ✓ Yes None None    Further property restrictions:\n\ngammaDelay.type  Allowed values:  GammaRandomDelay GammaSpeedDelay     \nconstantDelay Object to define a model for constant delay, which delivers always the same delay.\nProperties\n    Type Description Required Boundaries Default     type string Type of the constant delay ✓ Yes Enum    None   delay number\nstring The delay. If defined as a number, then the default unit is ns. Alternatively this can be defined as a string to include the unit of measurement (e.g. \u0026lsquo;3 seconds\u0026rsquo;) ✓ Yes None None    Further property restrictions:\n\nconstantDelay.type  Allowed values:  ConstantDelay     \nsimpleRandomDelay Object to define a model for a radnomised delay. Delivers number-of-steps different uniformly distributed delays in the interval defined by min and max (e.g. minDelay=30ms, maxDelay=60ms, steps=4 -\u0026gt; possible delays={30,40,50,60}ms.).\nProperties\n    Type Description Required Boundaries Default     type string Type of the delay. ✓ Yes Enum    None   steps integer Number of possible delays between min and max. ✓ Yes [0, +$\\infty$] None   minDelay number\nstring Minimum delay in nanoseconds for the Gamma distribution. If defined as a number, then the default unit is ns. Alternatively this can be defined as a string to include the unit of measurement (e.g. \u0026lsquo;3 seconds\u0026rsquo;) ✓ Yes None None   maxDelay number\nstring Maximum delay in nanoseconds for the Gamma distribution. If defined as a number, then the default unit is ns. Alternatively this can be defined as a string to include the unit of measurement (e.g. \u0026lsquo;3 seconds\u0026rsquo;) ✓ Yes None None    Further property restrictions:\n\nsimpleRandomDelay.type  Allowed values:  SimpleRandomDelay     \ntranmission Object to define the properties of a transmission.\nProperties\n    Type Description Required Boundaries Default     lossProbability number Probability of packet retransmission (in case of configured retries \u0026gt; 0) or packet loss (retries = 0) for the packet retransmission/loss model. A value of 0 equals a lossfree transmission. ✓ Yes [0, 1] 0   maxRetries integer Maximum Number of retransmissions. No [0, +$\\infty$] None    ","date":-62135596800,"expirydate":-62135596800,"kind":"section","lang":"en","lastmod":-62135596800,"objectID":"99fcd63e0ade62d27eee7393fc38c764","permalink":"https://www.eclipse.org/mosaic/docs/mosaic_configuration/sns_config/","publishdate":"0001-01-01T00:00:00Z","relpermalink":"/mosaic/docs/mosaic_configuration/sns_config/","section":"docs","summary":"You can use a Readable Unit anywhere where you have the option of:\n number or string integer or string     📃 Corresponding configuration file: sns/sns_config.json","tags":null,"title":"SNS Configuration","type":"docs"},{"authors":null,"categories":null,"content":" You can use a Readable Unit anywhere where you have the option of:\n number or string integer or string     📃 Corresponding configuration file: cell/cell_config.json\n \nCell This schema describes the JSON file structure for the cell configuration, which provides general configuration for the ambassador, such as paths to the regions and network configuration files.\nProperties\n    Type Description Required Boundaries Default     bandwidthMeasurementInterval number Interval in which the bandwidth is aggregated, given in seconds. No [1, +$\\infty$] 1   bandwidthMeasurementCompression boolean If enabled, the export files with bandwidth measurements will be compressed using gzip compression. No None false   networkConfigurationFile string Relative path to the network configuration file. ✓ Yes None network.json   regionConfigurationFile string Relative path to the region configuration file. No None regions.json   bandwidthMeasurements  bandwidthMeasurement[]   Measure the bandwidth between regions. No None None     \nbandwidthMeasurement Object to define the bandwidth measurement between regions.\nProperties\n    Type Description Required Boundaries Default     fromRegion string Measure the bandwidth of messages which originate in this region (use wildcard * for all regions). ✓ Yes None None   toRegion string Measure the bandwidth of messages which target in this region (use wildcard * for all regions). ✓ Yes None None   transmissionMode string Defines the transmission mode which is observed. ✓ Yes Enum    None   applicationClass string The application Class. No None *    Further property restrictions:\n\nbandwidthMeasurement.transmissionMode  Allowed values:  UplinkUnicast DownlinkUnicast DownlinkMulticast    ","date":-62135596800,"expirydate":-62135596800,"kind":"section","lang":"en","lastmod":-62135596800,"objectID":"71da21f61b9060d4480d42fd3fa1c950","permalink":"https://www.eclipse.org/mosaic/docs/mosaic_configuration/cell_config/","publishdate":"0001-01-01T00:00:00Z","relpermalink":"/mosaic/docs/mosaic_configuration/cell_config/","section":"docs","summary":"You can use a Readable Unit anywhere where you have the option of:\n number or string integer or string     📃 Corresponding configuration file: cell/cell_config.json","tags":null,"title":"Cell Simulator – Basic Configuration","type":"docs"},{"authors":null,"categories":null,"content":" You can use a Readable Unit anywhere where you have the option of:\n number or string integer or string     📃 Corresponding configuration file: cell/network.json\n \nNetwork Schema describing the JSON file structure for the network configuration. It is is used to define the properties of the global network. If defined as a number, then the default unit is Gb. Alternatively this can be defined as a string to specify the unit of measurement (e.g. \u0026lsquo;3 MB\u0026rsquo;).\nProperties\n    Type Description Required Boundaries Default     defaultDownlinkCapacity integer\nstring This downlink capacity value will be used for node-specific capacity calculation, if it wasn\u0026rsquo;t set in the cell configuration. If defined as a number, then the default unit is Gb. Alternatively this can be defined as a string to specify the unit of measurement (e.g. \u0026lsquo;3 MB\u0026rsquo;). No None 100 Gb   defaultUplinkCapacity integer\nstring This uplink capacity value will be used for node-specific capacity calculation, if it wasn\u0026rsquo;t set in the cell configuration. No None 100 Gb   globalNetwork  globalNetwork   Object to define all coverage properties of one region of the radio access network (ran-part). Such a configuration consists of one uplink-module and one downlink-module. In this context, uplink and downlink always refer to the direction TOWARDS and respectively FROM the GEO entity. ✓ Yes None None   servers  server   List of configured servers. No None None     \nglobalNetwork Object to define all coverage properties of one region of the radio access network (ran-part). Such a configuration consists of one uplink-module and one downlink-module. In this context, uplink and downlink always refer to the direction TOWARDS and respectively FROM the GEO entity.\nProperties\n    Type Description Required Boundaries Default     uplink  globalNetwork.uplink   Object to define the uplink of a network. The uplink direction only allows point-to-point communication (unicast). It is composed of the three nested models for delay, transmission configuration and capacity. ✓ Yes None None   downlink  globalNetwork.downlink   Object to define the downlink of a network. The downlink supports two individual paths: Point-to-point communication (unicast) and Point-to-multipoint communication (multicast). ✓ Yes None None     \nglobalNetwork.uplink Object to define the uplink of a network. The uplink direction only allows point-to-point communication (unicast). It is composed of the three nested models for delay, transmission configuration and capacity.\nProperties\n    Type Description Required Boundaries Default     delay  delay   Object to define a delay model. ✓ Yes None None   transmission  transmission   Object to define the properties of a transmission. ✓ Yes None None   capacity integer\nstring The capacity. ✓ Yes None None   maxCapacity number The maximal capacity when no transmission is ongoing. No None None     \ndelay Object to define a delay model.\nAdditionally ONE of the following property definitions apply:\n  gammaDelay    constantDelay    simpleRandomDelay     \ngammaDelay Object to define a model for GammaRandomDelay or GammaSpeedDelay. GammaRandomDelay bases directly on the Gamma distribution (b=2,p=2) with minimum and expected value. Due to the nature of the Gamma distribution, the resulting delays can be far higher than the expected value. GammaSpeedDelay bases on the GammaRandomDelay and includes an additional speed penalty according to the current speed of the vehicle.\nProperties\n    Type Description Required Boundaries Default     type string The type of delay. ✓ Yes Enum    None   minDelay number\nstring Minimum delay for the Gamma distribution. If defined as a number, then the default unit is ns. Alternatively this can be defined as a string to specify the unit of measurement (e.g. \u0026lsquo;3 seconds\u0026rsquo;) ✓ Yes None None   expDelay number\nstring Expected delay for the Gamma distribution. If defined as a number, then the default unit is ns. Alternatively this can be defined as a string to specify the unit of measurement (e.g. \u0026lsquo;3 seconds\u0026rsquo;) ✓ Yes None None    Further property restrictions:\n\ngammaDelay.type  Allowed values:  GammaRandomDelay GammaSpeedDelay     \nconstantDelay Object to define a model for constant delay, which delivers always the same delay.\nProperties\n    Type Description Required Boundaries Default     type string The type of delay. ✓ Yes Enum    None   delay number\nstring The delay. If defined as a number, then the default unit is ns. Alternatively this can be defined as a string to specify the unit of measurement (e.g. \u0026lsquo;3 seconds\u0026rsquo;) ✓ Yes None None    Further property restrictions:\n\nconstantDelay.type  Allowed values:  ConstantDelay     \nsimpleRandomDelay Object to define a model for a radnomised delay. Delivers number-of-steps different uniformly distributed delays in the interval defined by min and max (e.g. minDelay=30ms, maxDelay=60ms, steps=4 -\u0026gt; possible delays={30,40,50,60}ms.).\nProperties\n    Type Description Required Boundaries Default     type string The type of delay. ✓ Yes Enum    None   steps integer Number of possible delays between min and max. ✓ Yes [0, +$\\infty$] None   minDelay number\nstring Minimum delay in nanoseconds for the Gamma distribution. If defined as a number, then the default unit is ns. Alternatively this can be defined as a string to specify the unit of measurement (e.g. \u0026lsquo;3 seconds\u0026rsquo;) ✓ Yes None None   maxDelay number\nstring Maximum delay in nanoseconds for the Gamma distribution. If defined as a number, then the default unit is ns. Alternatively this can be defined as a string to specify the unit of measurement (e.g. \u0026lsquo;3 seconds\u0026rsquo;) ✓ Yes None None    Further property restrictions:\n\nsimpleRandomDelay.type  Allowed values:  SimpleRandomDelay     \ntranmission Object to define the properties of a transmission.\nProperties\n    Type Description Required Boundaries Default     lossProbability number Probability of packet retransmission (in case of configured retries \u0026gt; 0) or packet loss (retries = 0) for the packet retransmission/loss model. A value of 0 equals a lossfree transmission. ✓ Yes [0, 1] None   maxRetries integer Maximum Number of retransmissions. No [0, +$\\infty$] 0     \nglobalNetwork.downlink Object to define the downlink of a network. The downlink supports two individual paths: Point-to-point communication (unicast) and Point-to-multipoint communication (multicast).\nProperties\n    Type Description Required Boundaries Default     unicast  unicast   Point-to-point communication (unicast). ✓ Yes None None   multicast  multicast   Point-to-multipoint communication (multicast). ✓ Yes None None   capacity integer\nstring Shared capacity between unicast and multicast. ✓ Yes None None     \nunicast Point-to-point communication (unicast).\nProperties\n    Type Description Required Boundaries Default     delay  delay   Object to define a delay model. ✓ Yes None None   transmission  transmission   Object to define the properties of a transmission. ✓ Yes None None     \nmulticast Point-to-multipoint communication (multicast).\nProperties\n    Type Description Required Boundaries Default     delay  delay   Object to define a delay model. ✓ Yes None None   transmission  transmission   Object to define the properties of a transmission. ✓ Yes None None   usableCapacity number The usableCapacity configures the ratio of the overall downlink capacity allowed to be used. ✓ Yes [0, 1] None     \nserver Properties\n    Type Description Required Boundaries Default     id string Network-Id for identification. ✓ Yes None None   uplink  server.uplink   Object to define uplink properties of a network. The uplink direction only allows point-to-point communication (unicast). It is composed of the three nested models for delay, transmission configuration and capacity. No None None   downlink  server.downlink    No None None    The following additional properties are allowed:\n  undefined     \nserver.uplink Object to define uplink properties of a network. The uplink direction only allows point-to-point communication (unicast). It is composed of the three nested models for delay, transmission configuration and capacity.\nProperties\n    Type Description Required Boundaries Default     delay  delay   Object to define a delay model. ✓ Yes None None   transmission  transmission   Object to define the properties of a transmission. ✓ Yes None None    The following additional properties are allowed:\n  undefined     \nserver.downlink Properties\n    Type Description Required Boundaries Default     unicast  unicast   Point-to-point communication (unicast). ✓ Yes None None    The following additional properties are allowed:\n  undefined    ","date":-62135596800,"expirydate":-62135596800,"kind":"section","lang":"en","lastmod":-62135596800,"objectID":"8514240e2ce1a88f4228c2d190adaea8","permalink":"https://www.eclipse.org/mosaic/docs/mosaic_configuration/cell_network_config/","publishdate":"0001-01-01T00:00:00Z","relpermalink":"/mosaic/docs/mosaic_configuration/cell_network_config/","section":"docs","summary":"You can use a Readable Unit anywhere where you have the option of:\n number or string integer or string     📃 Corresponding configuration file: cell/network.json","tags":null,"title":"Cell Simulator – Network Configuration","type":"docs"},{"authors":null,"categories":null,"content":" You can use a Readable Unit anywhere where you have the option of:\n number or string integer or string     📃 Corresponding configuration file: cell/regions.json\n \nRegions Schema describing the JSON file structure for the regional networks configuration. It is is used to extend the network with regional information, which enables the emulation of mobile networks. If configured very granular, these regions can reflect cells as used in the real world. Though for most use-cases it is sufficient to approximate the behaviour by defining larger regions.\nProperties\n    Type Description Required Boundaries Default     regions  mobileNetworkProperties[]   An array of regional network configruations. No None None     \nmobileNetworkProperties Object to define a network with specific geograpgical extensions. It applies for all regions except the global network, which covers the remaining space. The CMobileNetworkProperties only needs to be employed, when geographic information are accessed.\nProperties\n    Type Description Required Boundaries Default     id string Network-Id for identification. No None None   area  geoRectangle   Object to define an immutable pair of two different geoPoints. Together they form a rectangular area. ✓ Yes None None   polygon object The area of the network as a polygon. ✓ Yes None None   uplink  mobileNetworkProperties.uplink   Object to define the uplink of a network. The uplink direction only allows point-to-point communication (unicast). It is composed of the three nested models for delay, transmission configuration and capacity. ✓ Yes None None   downlink  mobileNetworkProperties.downlink   Object to define the downlink of a network. The downlink supports two individual paths: Point-to-point communication (unicast) and Point-to-multipoint communication (multicast). ✓ Yes None None     \ngeoRectangle Object to define an immutable pair of two different geoPoints. Together they form a rectangular area.\nProperties\n    Type Description Required Boundaries Default     nw  geoPoint   Object to define geographical point coordinates. ✓ Yes None None   se  geoPoint   Object to define geographical point coordinates. ✓ Yes None None     \ngeoPoint Object to define geographical point coordinates.\nProperties\n    Type Description Required Boundaries Default     lon number East-west position of a point on earth. ✓ Yes [-180, 180] None   lat number North-south position of a point on earth. ✓ Yes [-$\\infty$, 90] None     \nmobileNetworkProperties.uplink Object to define the uplink of a network. The uplink direction only allows point-to-point communication (unicast). It is composed of the three nested models for delay, transmission configuration and capacity.\nProperties\n    Type Description Required Boundaries Default     delay  delay   Object to define a delay model. ✓ Yes None None   transmission  transmission   Object to define the properties of a transmission. ✓ Yes None None   capacity integer\nstring The capacity of the uplink. ✓ Yes None None     \ndelay Object to define a delay model.\nAdditionally ONE of the following property definitions apply:\n  gammaDelay    constantDelay    simpleRandomDelay     \ngammaDelay Object to define a model for GammaRandomDelay or GammaSpeedDelay. GammaRandomDelay bases directly on the Gamma distribution (b=2,p=2) with minimum and expected value. Due to the nature of the Gamma distribution, the resulting delays can be far higher than the expected value. GammaSpeedDelay bases on the GammaRandomDelay and includes an additional speed penalty according to the current speed of the vehicle.\nProperties\n    Type Description Required Boundaries Default     type string Type of Gamma delay. ✓ Yes Enum    None   minDelay number\nstring Minimum delay for the Gamma distribution. If defined as a number, then the default unit is ns. Alternatively this can be defined as a string to include the unit of measurement (e.g. \u0026lsquo;3 seconds\u0026rsquo;) ✓ Yes None None   expDelay number\nstring Expected delay for the Gamma distribution. If defined as a number, then the default unit is ns. Alternatively this can be defined as a string to include the unit of measurement (e.g. \u0026lsquo;3 seconds\u0026rsquo;) ✓ Yes None None    Further property restrictions:\n\ngammaDelay.type  Allowed values:  GammaRandomDelay GammaSpeedDelay     \nconstantDelay Object to define a model for constant delay, which delivers always the same delay.\nProperties\n    Type Description Required Boundaries Default     type string Type of the constant delay ✓ Yes Enum    None   delay number\nstring The delay, given in ns if defined as a number. Alternatively this can be defined as a string to include the unit of measurement (e.g. \u0026lsquo;3 seconds\u0026rsquo;) ✓ Yes None None    Further property restrictions:\n\nconstantDelay.type  Allowed values:  ConstantDelay     \nsimpleRandomDelay Object to define a model for a radnomised delay. Delivers number-of-steps different uniformly distributed delays in the interval defined by min and max (e.g. minDelay=30ms, maxDelay=60ms, steps=4 -\u0026gt; possible delays={30,40,50,60}ms.).\nProperties\n    Type Description Required Boundaries Default     type string Type of the delay. ✓ Yes Enum    None   steps integer Number of possible delays between min and max. ✓ Yes [0, +$\\infty$] None   minDelay number\nstring Minimum delay in nanoseconds for the Gamma distribution. If defined as a number, then the default unit is ns. Alternatively this can be defined as a string to include the unit of measurement (e.g. \u0026lsquo;3 seconds\u0026rsquo;) ✓ Yes None None   maxDelay number\nstring Maximum delay in nanoseconds for the Gamma distribution. If defined as a number, then the default unit is ns. Alternatively this can be defined as a string to include the unit of measurement (e.g. \u0026lsquo;3 seconds\u0026rsquo;) ✓ Yes None None    Further property restrictions:\n\nsimpleRandomDelay.type  Allowed values:  SimpleRandomDelay     \ntranmission Object to define the properties of a transmission.\nProperties\n    Type Description Required Boundaries Default     lossProbability number Probability of packet retransmission (in case of configured retries \u0026gt; 0) or packet loss (retries = 0) for the packet retransmission/loss model. A value of 0 equals a lossfree transmission. ✓ Yes [0, 1] 0   maxRetries integer Maximum Number of retransmissions. No [0, +$\\infty$] None     \nmobileNetworkProperties.downlink Object to define the downlink of a network. The downlink supports two individual paths: Point-to-point communication (unicast) and Point-to-multipoint communication (multicast).\nProperties\n    Type Description Required Boundaries Default     unicast  unicast   Object to define point-to-point communication. ✓ Yes None None   multicast  multicast   Object to define point-to-multipoint communication. ✓ Yes None None   capacity integer\nstring The capacity of the downlink. ✓ Yes None None     \nunicast Object to define point-to-point communication.\nProperties\n    Type Description Required Boundaries Default     delay  delay   Object to define a delay model. ✓ Yes None None   transmission  transmission   Object to define the properties of a transmission. ✓ Yes None None     \nmulticast Object to define point-to-multipoint communication.\nProperties\n    Type Description Required Boundaries Default     delay  delay   Object to define a delay model. ✓ Yes None None   transmission  transmission   Object to define the properties of a transmission. ✓ Yes None None   usableCapacity number The usableCapacity configures the ratio of the overall downlink capacity allowed to be used. ✓ Yes [0, 1] None    ","date":-62135596800,"expirydate":-62135596800,"kind":"section","lang":"en","lastmod":-62135596800,"objectID":"363f152566a6299e87f2b3255e9dfe57","permalink":"https://www.eclipse.org/mosaic/docs/mosaic_configuration/cell_region_config/","publishdate":"0001-01-01T00:00:00Z","relpermalink":"/mosaic/docs/mosaic_configuration/cell_region_config/","section":"docs","summary":"You can use a Readable Unit anywhere where you have the option of:\n number or string integer or string     📃 Corresponding configuration file: cell/regions.json","tags":null,"title":"Cell Simulator – Region Configuration","type":"docs"},{"authors":null,"categories":null,"content":" You can use a Readable Unit anywhere where you have the option of:\n number or string integer or string     📃 Corresponding configuration file: sumo/sumo_config.json\n \nSUMO Schema describing the JSON file structure for the SUMO configuration.\nProperties\n    Type Description Required Boundaries Default     updateInterval string\nnumber The Interval after which positions are published. If defined as a number, then the default unit is ms. Alternatively this can be defined as a string to include the unit of measurement (e.g. \u0026lsquo;1 s\u0026rsquo;). Define the size of one simulation step in sumo. No None 1000   sumoConfigurationFile string Name of the main SUMO scenario configuration (*.sumocfg). If this member equals null, the SUMO ambassador will try to find a \u0026lsquo;.sumocfg\u0026rsquo; file. No None None   exitOnInsertionError boolean If too many vehicles try to enter the simulation, SUMO might skip some vehicles and tries to enter them later again. This behavior can lead to wrong simulation results. This parameter defines, if the ambassador should try to continue the simulation in such cases. Quit SUMO, if an error occurs while inserting a new vehicle (e.g. due to high vehicle densities) (recommended: true). No None true   additionalSumoParameters string Add additional parameters to the SUMO start command. Set a particular seed for the random number generator. By using different values you can have different but still reproducible simulation runs. Ignore possible waiting times by setting time-to-teleport to 0. This avoids unmoved vehicles (in our case also RSUs) being removed from simulation. No None --time-to-teleport 0 --seed 100000   trafficFlowMeasurementWindowInS integer Defines the time window in seconds in which vehicle counts on induction loops should be aggregated to traffic flow. The value should be given in veh/h. No [1, +$\\infty$] 300   timeGapOffset number This offset is added to all time-gap related parametrizations of vehicles (e.g. declaring vehicle types to SUMO, changing time-gap/reaction time during simulation). This could be helpful as IDM should be parametrized with lower time gaps to achieve specific time gap values. No None 0   subscribeToAllVehicles boolean If set to true all vehicles will be subscribed. If set to false only vehicles with applications mapped to them will be subscribed. No None true   subscriptions string[] An optional list of subscriptions for each vehicle in the simulation. The less subscriptions given, the faster the simulation. Per default (if this list is set to null), all subscriptions are activated. Please note, that some components expect specific information, such as the road position. If this information is not subscribed, these components may fail. No None None   trafficSignLaneWidth number The default lane width to be used when adding traffic signs per lane (only relevant when using SUMO-GUI) No [0.1, +$\\infty$] 3.2   highlights string[] Configure to highlight a vehicle in the GUI if it\u0026rsquo;s performing a route or lane change, e.g. for debugging purposes (only relevant when using SUMO-GUI). No None None   additionalVehicleTypeParameters object Allows to configure specialised vType parameters, which can\u0026rsquo;t be configured via mapping (e.g. parameters for the lane change model of vehicles). The key of this object has to match with the name of a protype defined in the mapping configuration. No None None    Further property restrictions:\n\nSUMO.additionalVehicleTypeParameters  Type of each property: additionalVehicleType   \nadditionalVehicleType Object to define a specialised vType.\nThe following additional properties are allowed:\n  additionalParameter     \nadditionalParameter The vehicle parameter.\n","date":-62135596800,"expirydate":-62135596800,"kind":"section","lang":"en","lastmod":-62135596800,"objectID":"04f8a0e4239211b6023ba30854186581","permalink":"https://www.eclipse.org/mosaic/docs/mosaic_configuration/sumo_config/","publishdate":"0001-01-01T00:00:00Z","relpermalink":"/mosaic/docs/mosaic_configuration/sumo_config/","section":"docs","summary":"You can use a Readable Unit anywhere where you have the option of:\n number or string integer or string     📃 Corresponding configuration file: sumo/sumo_config.json","tags":null,"title":"SUMO Configuration","type":"docs"},{"authors":null,"categories":null,"content":"This online documentation provides detailed information for the latest release of Eclipse MOSAIC. Some details may deviate, however, as we constantly keep this documentation in sync with the current main branch of our  GitHub repository  .\nThis documentation is accompanied by our  tutorials  . Generally, it is recommended to read the documentation first, especially the sections on How To Get Started  and Simulator Overview  . For external simulators like Eclipse SUMO, OMNeT++ / INET or ns-3, the according project websites contain more exhaustive information, of course.\n Our tutorials are intended for step-by-step practical learning. It should be possible to start them right away without prior experience with Eclipse MOSAIC. However, for several aspects, the documentation should be consulted at least in parallel.\n   The search allows jumping directly to specific topics in the documentation.\n  1.\u0026nbsp; Getting Started Download and installation.Learn more    2.\u0026nbsp; Visualization Visualize and evaluate simulation results.Learn more    3.\u0026nbsp; Simulators Configure external and integrated simulators.Learn more    4.\u0026nbsp; Building Scenarios Build your own simulation scenarios.Learn more    5.\u0026nbsp; Create Applications Develop applications for the Application Simulator.Learn more    6.\u0026nbsp; Extending Eclipse MOSAIC Extend Eclipse MOSAIC.Learn more    7.\u0026nbsp; MOSAIC Configuration Complete documentation of configuration files.Learn more    8.\u0026nbsp; API Documentation Technical documentation, such as Javadoc.Learn more     ","date":1596672000,"expirydate":-62135596800,"kind":"section","lang":"en","lastmod":1596672000,"objectID":"4cdd37113783e47641dd300543c94e1b","permalink":"https://www.eclipse.org/mosaic/docs/","publishdate":"0001-01-01T00:00:00Z","relpermalink":"/mosaic/docs/","section":"docs","summary":"This online documentation provides detailed information for the latest release of Eclipse MOSAIC. Some details may deviate, however, as we constantly keep this documentation in sync with the current main branch of our  GitHub repository  .","tags":null,"title":"Eclipse MOSAIC Documentation","type":"docs"},{"authors":null,"categories":null,"content":"Eclipse MOSAIC has different classes, which allow you to define the network type and the specific area where the communication should occur. Communication can be achieved with external network simulators (, ns-3  ) or one of the built-in communication simulators SNS  or Eclipse MOSAIC Cell  . Furthermore, for a better understanding it is important to consider the network types of Eclipse MOSAIC in more detail.\n Cellular Communication Ad-hoc Communication  Depending on the needs of the application, there are different approaches to solve the communication issue in Eclipse MOSAIC simulations. However, a distinction must be made between inter vehicle communication and Vehicle-to-X communication. Also, it is possible to modify the selected communication mode dependent on requirements.\nGenerally, the following modes are available based on network:\nCellular Communication\n Geobroadcast Geocast Topocast  Ad-hoc Communication\n Geobroadcast Geocast Topobroadcast Topocast   Cellular Communication The cellular network is known from wireless mobile communication and the principle is to divide the entire geographic area into several smaller parts called \u0026ldquo;cells\u0026rdquo;. Each cell has a fixed-location transceiver with a coverage ratio.\nEclipse MOSAIC enables the communication with all the existing vehicles via Geobroadcast mode or direct communication via Geocast in a specific area (circular, rectangular). In contrast, the Topocast mode is not restricted to a specific area.\nCellular Geobroadcast The principle function of the Geobroadcast is to communicate with all entities within a geographical area. Eclipse MOSAIC offers the possibility to configure a specific geographical area which can be either a circular or a rectangular area.\nThe following figure illustrates a vehicle veh_2 which is communicating with the other vehicles(veh_1, veh_3) within a radius R.\n Illustration of Geobroadcast in a spezific circular area   A circular communication area can be defined with the geoBroadCast(GeoCircle geoCircle) from an Eclipse MOSAIC application, as shown below:\nGeoCircle transmissionArea = new GeoCircle(GeoPoint.latlon(52.5, 13.2), 3000); MessageRouting routing = getOs().getCellModule().createMessageRouting().geoBroadCast(transmissionArea); getOs().getCellModule().sendV2XMessage(new MyV2XMessage(routing));  A rectangular destination area can be defined similarly:\nGeoPoint pointA = GeoPoint.latlon(52.51355, 13.22000); GeoPoint pointB = GeoPoint.latlon(52.52000, 13.21000); GeoRectangle transmissionArea = new GeoRectangle(pointA, pointB); MessageRouting routing = getOs().getCellModule().createMessageRouting().geoBroadCast(transmissionArea); getOs().getCellModule().sendV2XMessage(new MyV2XMessage(routing));  Cellular Geocast Compared to Geobroadcasting, a Geocast addresses a receiver with an unique address. Addressing can be in the form of an IP-Address or a receiver-ID (e.g. veh_0). Again, the communication area can be configured as circular or rectangular.\nAssume, the veh_1 has a message which is addressed to veh_2. In order to send the message, veh_1 first examines whether the vehicle with ID veh_2 is located within the transmission area. If this is the case, the message will be transmitted. In figure below is this situation illustrated.\n Cellular Geocast to address a receiver within a defined area   The following methods are provided for the configuring the transmission area (Circle or Rectangle) and the addressing to the receiver(hostname or ip address).\n geoCast(GeoCircle geoCircle, String receiverName)  geoCast(GeoRectangle geoRectangle, String receiverName) geoCast(GeoCircle geoCircle, byte[] ipAddress) geoCast(GeoRectangle geoRectangle, byte[] ipAddress)  GeoCircle transmissionArea = new GeoCircle( GeoPoint.latlon(52.5, 13.2), 3000); String receiverName = \u0026quot;veh_0\u0026quot;; MessageRouting routing = getOs().getCellModule().createMessageRouting().geoCast(transmissionArea, receiverName); getOs().getCellModule().sendV2XMessage(new MyV2XMessage(routing));  Cellular Topocast Compared to Geocast or Geobroadcast, the Topocast is totally independent of geographical conditions and the addressing can be in the form of an IP-Address or a receiver-ID.\nThe next figure illustrates how the veh_0 is communicating with veh_1 in Topocast mode.\n Topocast mode for direct addressing without geographical constraints   The code example below shows how we can configure the requirements of the communication in Topocast mode.\nString receiverName = \u0026quot;veh_0\u0026quot;; MessageRouting routing = getOs().getCellModule().createMessageRouting().topoCast(receiverName); getOs().getCellModule().sendV2XMessage(new MyV2XMessage(routing));  Setting Protocol types By default, all cell messages use UDP, however you can set the protocol using the protocol(...) method of the MessageRoutingBuilder:\nString receiverName = \u0026quot;veh_0\u0026quot;; MessageRouting routing = getOs().getCellModule().createMessageRouting() .protocol(Protocoltype.TCP) .topoCast(receiverName); getOs().getCellModule().sendV2XMessage(new MyV2XMessage(routing));   Ad-hoc Communication The Ad-hoc network does not rely on a pre-existing infrastructure. Provided that vehicles are equipped with Ad-hoc modules, they are able to communicate with each other dynamically. In case of a sufficient number of Ad-hoc equipped vehicles, a message can be transferred via hops quickly over a long distance.\nEclipse MOSAIC also enables the communication via a specific Ad-hoc channel within the wireless Ad-hoc network. However, the Ad-hoc channels for vehicular communication are limited and standardized by the IEEE 802.11p. The licensed frequency band 5.9 GHz (5.85-5.925 GHz) for Intelligent Transportation Systems(ITS) will be used as Ad-hoc channels.\nThe following table shows the possible channels on the 5.9 GHz band used for V2X communication.\n   Channel Number 0 1 2 3 4 5 6     Channel Name SCH1 SCH2 SCH3 CCH SCH4 SCH5 SCH6   Frequency Band 5.86 5.87 5.88 5.89 5.9 5.91 5.92    Configuring AdHoc Capabilities The first step to enable your application to use Ad hoc capabilities, is to make sure it extends the AbstractSimulationUnit-class or one of its child-classes (e.g. VehicleUnit, ChargingStationUnit) found in package org.eclipse.mosaic.fed.application.ambassador.simulation. Additionally, if you want your application to act upon the reception or transmission of messages, make sure it implements the interface CommunicationApplication.\nOnce this is done, make sure to configure and enable the AdHoc-module in your application. Below is an example configuration taken from the Tiergarten-tutorial. Instead of configuring the .power(...)[mW] it is also possible to configure a .distance(...)[m].\n// Example of AdHocConfiguration (see TiergartenVehicle.java) @Override public void onStartup() { getOs().getAdHocModule().enable(new AdHocModuleConfiguration() .addRadio() .channel(AdHocChannel.CCH) .power(50) .create()); }  Ad-hoc Topobroadcast In Topobroadcast mode, the communication between vehicles is regardless of the geographic conditions. However, the communicating entities must be operated on the same Ad-hoc channel and there are two options to use the Topobroadcast:\n Singlehop Multihop  Singlehop approach in Topobroadcast For Singlehop, it is not necessary to specify the number of hops explicitly which indicates the lifespan of a message, because in Singlehop, any message has a lifespan of hop = 1. Moreover, Eclipse MOSAIC allows to use the default method topoBroadCast() which automatically assigns a Control Channel (CCH) for the simulation entity and a lifespan based on the Singlehop principle. Alternatively you can use the non-default method topoBroadCast(AdHocChannel) in order to specify the Ad-hoc channel.\nBelow are some configuration examples of the default addressing method topoBroadCast() and non-default addressing method topoBroadCast(AdHocChannel).\nMessageRouting routing = getOs().getAdHocModule().createMessageRouting().topoBroadCast(); getOs().getAdHocModule().sendV2XMessage(new MyV2XMessage(routing));  AdHocChannel commonChannel = AdHocChannel.SCH1; MessageRouting routing = getOs().getAdHocModule().createMessageRouting().topoBroadCast(commonChannel); getOs().getAdHocModule().sendV2XMessage(new MyV2XMessage(routing));  The following figure shows a simplified model based on the Singlehop principle. The veh_1 sends messages to all simulation entites(RSU, veh_2) that are using the same Ad-hoc channel. After transmission, the message can no longer be forwarded by the receiver.\n Overview Singlehop with specified Ad-hoc channel   Multihop approach in Topobroadcast In Multihop, the lifespan (amount of hops) of a message can be specified, allowing larger communication distances.\nThe following figure shows a Multihop example with a data package D (M, h = 2) from the vehicle veh_0 which contains a message M and a hop number h = 2. Assuming that a lot of simulation entities are using the same Ad-hoc channel the message can be forwarded over a along distance. After each forward the hop number will be incremented by 1. Since the hop amount was set to 2, the forwarding will stop after 2 increments.\n Overview Multihop principle   The next code snippet shows a configuration example with an Ad-hoc channel and a message lifespan hops = 2.\nAdHocChannel commonChannel = AdHocChannel.SCH1; int hops = 2; MessageRouting routing = getOs().getAdHocModule().createMessageRouting().topoBroadCast(commonChannel, hops); getOs().getAdHocModule().sendV2XMessage(new MyV2XMessage(routing));   In order to use the Multihop approach in OMNeT++ and ns-3 provided by Eclipse MOSAIC, its necessary to implement a routing protocol in network simulators (OMNeT++, ns-3). But the built in communication simulator SNS includes a simple routing protocol “Flooding”.\n  Ad-hoc Topocast In addition to the Topobroadcast, the communication in Topocast mode will be addressed explicitly to the recipient and the addressing can be done either through receiver name (vehicle-ID e.g. veh_0) or the IP-Address of the vehicle.\nfinal byte[] ipv4Address = {127,36,50,4}; AdHocChannel commonChannel = AdHocChannel.SCH1; int hops = 2; MessageRouting routing = getOs().getAdHocModule().createMessageRouting().topoCast(ipv4Address, hops, commonChannel); getOs().getAdHocModule().sendV2XMessage(new MyV2XMessage(routing));  Ad-hoc Geobroadcast In contrast to Cellular Network above, the simulation entities act as active communication part (transmitter and receiver) and all simulation entities within range are getting messages in Geobroadcast mode.\nAs example in the following illustration, The vehicles veh_0, veh_2, veh_3 and the RSU are Ad-hoc equipped and there is no vehicle in the communication range of RSU, therefore a hop is not possible to next vehicle veh_0. But the vehicles veh_2 and veh_3 are able to communicate with each other.\n Principle of Ad-hoc Geobroadcast mode   With the methods\n geoBroadCast(GeoCircle geoCircle) geoBroadCast(GeoRectangle geoRectangle)  of the Eclipse MOSAIC class AdHocMessageRoutingBuilder ,we are able, to configure the required area as a circle or a rectangle.\nGeoPoint center = GeoPoint.latlon(52.5, 13.2); GeoCircle adHocModule = new GeoCircle(center, 3000); MessageRouting routing = getOs().getAdHocModule().createMessageRouting().geoBroadCast(adHocModule); getOs().getAdHocModule().sendV2XMessage(new MyV2XMessage(routing));  Analogous to the examples above, we can also configure the transmission area as a rectangle.\nThe next code snippet illustrates a possible configuration with a rectangular transmission area and a specified Ad-hoc channel.\nGeoPoint pointA = GeoPoint.latlon(52.51355, 13.22000); GeoPoint pointB = GeoPoint.latlon(52.52000, 13.21000); final double radius = 3000.0; GeoRectangle transmissionArea = new GeoRectangle(pointA, pointB); MessageRouting routing = getOs().getAdHocModule().createMessageRouting().geoBroadCast(transmissionArea, AdHocChannel.SCH1); getOs().getCellModule().sendV2XMessage(new MyV2XMessage(routing));  Ad-hoc Geocast The class AdHocMessageRoutingBuilder only has one method for Geocasting mode, geoCast(DestinationAddress destinationAddress, AdHocChannel adHocChannel). Communication is possible if the IP-address of receiver is known and both (receiver and transmitter) are on the same Ad-hoc channel.\n In this context the name Geocast is misleading, because a geological condition is not necessary.\n  As you can see in the next picture, the RSU uses the Ad-hoc channel SCH1 and several vehicles use different Ad-hoc channels. Assuming the RSU tries to send a message to veh_1 and has knowledge about the IP-Address of veh_1, if the vehicle veh_1 also uses the same channel SCH1, the transmission will be completed successfully.\n Ad-hoc Geocast communication between entities using the same channel   Below you can see a possible configuration.\nfinal byte[] ipv4Address = {127,36,50,4}; DestinationAddress destAddress = new DestinationAddress(ipv4Address); AdHocChannel commonChannel = AdHocChannel.SCH1; MessageRouting routing = getOs().getAdHocModule().createMessageRouting().geoCast(destAddress, commonChannel); getOs().getAdHocModule().sendV2XMessage(new MyV2XMessage(routing));  CAM - Implementation A Cooperative Awareness Messages (CAM) consists of four parts:\n Header with generic information MessageBody ServiceList TaggedValue list  First, generic information like protocol version, creation time stamp are submitted. Normally this data set follows a network beacon, which already contains data like position and speed. Nevertheless, this functionality must be implemented in the network layer, that means 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 can contain either RSU or Vehicle awareness data. In the first case, only the RSU type is submitted, but this probably changes with a new CAM specification. In the second case, we provide date like vehicle width, length, position, speed, type and heading. The specification is not completely implemented, especially acceleration data and light, brake status are missing. The third part of the CAM specification, the service list, is also not implemented. This will probably change, when a list of services is defined by the ETSI. Last but not least a message contains a tagged list, a key value map with optional data. This is fully implemented and is used for our traffic light CAM messages, which provide the traffic light status in such a list.\nUser defined tagged values If you are required to exchange custom data within CAMs, the field UserTaggedValue can be used. For adding such data to the CAM, the application needs to implement the method beforeGetAndResetUserTaggedValue() from the CommunicationApplication interface. If a CAM is about to be sent, the custom data can be set using the getOs().setUserTaggedValue(byte[]) method. The receiver can simple access the data by accessing the field directly from the received CAM message:\nbyte[] value = cam.getUserTaggedValue (); if (value != null) { // read user tagged value} }  Timing Requirements CAMs are generated by the CAM Management and passed to lower layers when any of following rules apply:\n maximum time interval between CAM generations: $1s$; minimum time interval between CAM generations: $0.1s$; generate CAM when absolute difference between current heading (towards North) and last CAM heading \u0026gt; $4 deg$; generate CAM when distance between current position and last CAM position \u0026gt; $5m$ generate CAM when absolute difference between current speed and last CAM speed \u0026gt; $1ms$; These rules are checked latest every $100ms$;  ","date":1557010800,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1557010800,"objectID":"d32a5f22c5ae5d143ef2bc4c35a326c8","permalink":"https://www.eclipse.org/mosaic/docs/develop_applications/communication/","publishdate":"2019-05-05T00:00:00+01:00","relpermalink":"/mosaic/docs/develop_applications/communication/","section":"docs","summary":"Eclipse MOSAIC has different classes, which allow you to define the network type and the specific area where the communication should occur. Communication can be achieved with external network simulators (, ns-3  ) or one of the built-in communication simulators SNS  or Eclipse MOSAIC Cell  .","tags":null,"title":"Communication in Applications","type":"docs"},{"authors":null,"categories":null,"content":"The different modules of the Application Simulator  communicate over events that are triggered at a specific simulation time. The following classes and interfaces model theses events.\nEvent The class Event contains the information that is necessary to process an event. An event describes when it should be processed and which information is processed. Moreover an event has an assigned priority.\nAttributes of Event The class Event contains the following attributes:\n long time: defines the time when the execution of the event is triggered. long nice: defines the priority of the event. When multiple events are scheduled for the sametime, the events are ordered in ascending order. List\u0026lt;EventProcessor\u0026gt; processors: is a list of components that shall process the event. Object resource: is an object that contains additional information designated for the processor of the event. The resource can be any object.  Methods of Event  Event(): There are multiple constructors for Event with different parameters. Every constructor sets default values for the attributes that are not defined by the arguments of the constructor. Event newTime(long time): allows the creation of a new event with a new execution time based String getResourceSimpleClassName(): returns the class name of the resource as String. int compareTo(Event event): implements the standardized Java interface Comparable  . Toorder the events, first the time of the event is evaluated. In case the times are equal, the priority of the events is compared.  Interface EventManager The interface EventManager defines the method void addEvent(Event event) that needs to be implemented to add an event to the execution.\nInterface EventScheduler The interface EventScheduler extends the interface EventManager and is used for classes that trigger events.\nMethods of EventScheduler  boolean isEmpty(): returns true if the scheduler contains no elements, otherwise it returns false. long getNextEventTime(): returns the time of the next event. long getScheduledTime(): returns the time when the last event has been executed. List\u0026lt;Event\u0026gt; scheduleEvents(long time): returns a list of objects that are scheduled for a certain simulation time. Set\u0026lt;Event\u0026gt; getAllEvents(): returns a set of all events that are considered by the scheduler.  EventSchedulerImpl The class EventSchedulerImpl is an implementation of the interface EventScheduler.\nInterface EventProcessor The interface EventProcessor defines how the execution module gets the events. The execution module therefore has to implement the following methods:\n void processEvent(Event event): The module processes the event. boolean canProcessEvent(): returns true when the module is currently able to process new events, otherwise it returns false.  InterceptedEvent Class EventInterceptor In some situation it is useful to intercept events before they actually reach the intended processors. By intercepting the events it is possible to apply further monitoring and to filter which events the event processors receive. The class EventInterceptor is used to construct objects of the type InterceptedEvent. In the constructor it is possible to specify an EventManager that manages the intercepted events. Moreover, objects of the type EventProcessor can be specified that shall process the intercepted events.\nClass InterceptedEvent The class InterceptedEvents extends the class Event. It is used to provide type safe allocations of events that shall be intercepted.\n","date":1565481600,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1565481600,"objectID":"77fcc6d6f359287fbc8c37d7e6c54048","permalink":"https://www.eclipse.org/mosaic/docs/develop_applications/event_scheduler/","publishdate":"2019-08-11T00:00:00Z","relpermalink":"/mosaic/docs/develop_applications/event_scheduler/","section":"docs","summary":"The different modules of the Application Simulator  communicate over events that are triggered at a specific simulation time. The following classes and interfaces model theses events.\nEvent The class Event contains the information that is necessary to process an event.","tags":null,"title":"Event Scheduling","type":"docs"},{"authors":null,"categories":null,"content":"Each scenario to be simulated with Eclipse MOSAIC requires a database which contains information about the road infrastructure and routes the vehicles drive on. This information is used by various federates. For example, the SUMO federate needs to know initial routes for vehicles, and the Application Simulator  requires detailed information about the road infrastructure to provide applications with methods for route calculation. For this purpose, an embedded SQLite database is used which is placed in the application folder of the scenario. This database consists of the following tables:\nDatabase tables    Database Name Description     Node Contains all Nodes of the road network such as junctions and nodes describing the geometry of a road. Each node is identified by an unique ID (long).(refer to http://wiki.openstreetmap.org/wiki/Node)   Way Provides various properties for each way of the road network.(refer to http://wiki.openstreetmap.org/wiki/Way   WayConsistsOf Provides a list of nodes for each way of the road network.   Connection Contains a list of all connections of the road network including the way it originally is part of. Each connection describes an directed edge between two junctions in the road network.   ConnectionConsistsOf Provides a list of nodes each connection consists of.   Restriction Provides information about turn restrictions. Each turn restriction is described by a from-connection, a via-node, and a to-connection. This data is used for route calculation purposes.   TrafficSignals Contains detailed information about traffic lights and their signalling program. Currently not used.   Route Contains a list of all routes known for the simulation scenario. All routes referenced in the Mapping configuration must be presentin this table.   Building Corner Wall Provides information about buildings alongside the road network, e.g. for visualization purposes or sophisticated communication simulation models.   Version Contains the version of the Eclipse MOSAIC installation which was initially used to create the database.    Road network model This section describes the model of the road network used by various components of Eclipse MOSAIC. In the next figure various nodes and connections can be seen. A node is either a junction or describes the geometry of a road. A connection is a directed edge between two junction nodes. That also means, that two separate connections exists for a road segment which can be traversed in both directions. Each connection consists of at least two nodes (start and end junction node). Between those nodes, other nodes can exist which describe the curvature of the road segment. Furthermore, each connection has a reference to its originating way, which may consist of various connections. A way contains further properties, such as the maximum speed or the type of the road.\n Nodes and connections of the road network   Nodes and ways are identified by unique IDs derived from the base OSM network file. Connections, however, are not part of the OSM standard and their identifiers are generated during the import. Each connection ID consists of three parts (using the string pattern aaa_bbb_ccc):\n aaa - ID of the originating way bbb - ID of the node the connection starts at. ccc - ID of the node the connection ends in.   ID of connection in road network   Some components of Eclipse MOSAIC need to identify further parts of the road network, such as one edge between two nodes, or one specific lane of one edge. Therefore, the following objects are identified as following:\nEdges are described by one start and one end node. The identifier of an edge consists of two parts (using the string pattern aaa_bbb_ccc_ddd):\n aaa_bbb_ccc - ID the connection the edge belongs to. ddd - ID of the node the edge starts at.   Structure of the Edge-ID   Lanes are described by an edge and a lane index. The identifier of a lane consists of two parts (using the string pattern aaa_bbb_ccc_ddd_e):\n aaa_bbb_ccc_ddd - ID the edge the lane belongs to. e - Index of the lane, starting by 0 (leftmost lane).   Structure of the Lane-ID   ","date":1565049600,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1565049600,"objectID":"1d92f8a189d6829395465481d4b2ddad","permalink":"https://www.eclipse.org/mosaic/docs/develop_applications/road_traffic/","publishdate":"2019-08-06T00:00:00Z","relpermalink":"/mosaic/docs/develop_applications/road_traffic/","section":"docs","summary":"Each scenario to be simulated with Eclipse MOSAIC requires a database which contains information about the road infrastructure and routes the vehicles drive on. This information is used by various federates.","tags":null,"title":"Scenario Database","type":"docs"},{"authors":null,"categories":null,"content":"","date":-62135596800,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":-62135596800,"objectID":"ad9ca34c3728e0522fcf5122cbadab93","permalink":"https://www.eclipse.org/mosaic/group/fokus/","publishdate":"0001-01-01T00:00:00Z","relpermalink":"/mosaic/group/fokus/","section":"group","summary":"The **Fraunhofer Institute for Open Communication Systems (FOKUS)** is the leading group behind the simulation framework Eclipse MOSAIC, which has now been developed over the last 12 years in close cooperation with the DCAITI of the TU Berlin and has already been used by more than 600 partners and researches to test smart mobility services and intelligent traffic scenarios.","tags":null,"title":"","type":"group"},{"authors":null,"categories":null,"content":"The File Output Generator is a tool which gives you the opportunity to log specific Eclipse MOSAIC interaction types. For each interaction the File Output receives, one line (or more in case of an iteration object) is added to a CSV output file. This allows to track the movements of vehicles or to monitor the V2X message exchange.\nOne example output could be the following:\nCELL_CONFIGURATION;6000000000;veh_0;true;7200000000;1400000000 V2X_MESSAGE_TRANSMISSION;6000000000;DENM;3;rsu_0;52.65027;13.545;0.0;CELL_GEOCAST;/255.255.255.255;null VEHICLE_UPDATES;7000000000;veh_0;35.501624617716296;186.33236029307432;52.655993308955196;13.569065826100868;0.0;35.501624617716296;-0.6083753822837039;0.0;false;1;4067968_28830219_3290027832_2450938914;0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;false;false;false VEHICLE_REGISTRATION;7000000000;veh_1;ElectricVehicle;null;Unequipped;5.0;2.5;70.0;2.6;4.5;0.5;1.0;1.0;0.0;1;1;0.0 VEHICLE_UPDATES;8000000000;veh_0;34.978651295430026;186.33236029306624;52.65568017869267;13.569019012494635;0.0;70.48027591314633;-0.5229733222862691;0.0;false;1;4067968_28830219_3290027832_2450938914;0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;false;false;false V2X_MESSAGE_TRANSMISSION;8000000000;DENM;4;rsu_0;52.65027;13.545;0.0;CELL_GEOCAST;/255.255.255.255;null VEHICLE_UPDATES;9000000000;veh_0;35.73455352933612;186.33236029306624;52.65536028153272;13.56897118787549;0.0;106.21482944248245;0.7559022339060917;0.0;false;1;4067968_28830219_3290027832_2450938914;0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;false;false;false VEHICLE_UPDATES;9000000000;veh_1;35.52345835176762;186.33265000325784;52.65599046030636;13.569112899208802;0.0;35.52345835176762;-0.5865416482323766;0.0;false;1;4067968_28830219_3290027832_2450938914;1;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;0.0;false;false;false  Configuring the FileOutput  The main configuration file is located at \u0026lt;mosaic-root\u0026gt;/scenarios/\u0026lt;scenarioName\u0026gt;/output/output_config.xml  Basic configuration The following listing shows a basic example for the configuration of the FileOutput:\n\u0026lt;?xml version=\u0026quot;1.0\u0026quot; encoding=\u0026quot;UTF-8\u0026quot;?\u0026gt; \u0026lt;output id=\u0026quot;fileoutput\u0026quot; enabled=\u0026quot;true\u0026quot; update=\u0026quot;5\u0026quot; loader=\u0026quot;org.eclipse.mosaic.fed.output.generator.file.FileOutputLoader\u0026quot;\u0026gt; \u0026lt;filename\u0026gt;output.csv\u0026lt;/filename\u0026gt; \u0026lt;directory\u0026gt;.\u0026lt;/directory\u0026gt; \u0026lt;separator\u0026gt;;\u0026lt;/separator\u0026gt; \u0026lt;subscriptions\u0026gt; \u0026lt;subscription id=\u0026quot;...\u0026quot;\u0026gt; ... \u0026lt;/subscription\u0026gt; ... \u0026lt;/subscriptions\u0026gt;\u0026gt; \u0026lt;/output\u0026gt;  Basic configuration parameters for FileOutput\nThe usage of the parameters is described in the following table:\n   Parameter Usage     id Sets the id for the output   enabled If set to \u0026ldquo;false\u0026rdquo;, output is not used (default value is \u0026ldquo;true\u0026rdquo;)   update Sets the update interval in seconds for the output   start Sets the start time in seconds for output generation. This has nothing to do with the run time of the actual simulation   end Sets the end time in seconds for output generation. This has nothing to do with the run time of the actual simulation   loader Sets where the output is loaded from using the Java-class (see previous listing)    Basic Configuration of file output\nInteraction record Each interaction record is derived from a certain interaction type and composed of several entries,which are separated by Element separator.\nThe configuration of the file output is explained at the example of the VehicleUpdates interaction:\n\u0026lt;subscription id=\u0026quot;VehicleUpdates\u0026quot; enabled=\u0026quot;true\u0026quot;\u0026gt; \u0026lt;entries\u0026gt; \u0026lt;entry\u0026gt;\u0026quot;UPDATE_VEHICLE\u0026quot;\u0026lt;/entry\u0026gt; \u0026lt;entry\u0026gt;Time\u0026lt;/entry\u0026gt; \u0026lt;entry\u0026gt;Updated:Name\u0026lt;/entry\u0026gt; \u0026lt;entry\u0026gt;Updated:Speed\u0026lt;/entry\u0026gt; \u0026lt;entry\u0026gt;Updated:Position.Latitude\u0026lt;/entry\u0026gt; \u0026lt;entry\u0026gt;Updated:Position.Longitude\u0026lt;/entry\u0026gt; \u0026lt;/entries\u0026gt; \u0026lt;/subscription\u0026gt;  Specific Configuration for interaction\n Attribute id indicates the interaction type, namely the class name of the interaction. The element entries defines the format and content of the handled subscription record. The element entries is composed of several sub-elements entry, which correspond to columns of a subscription record and the sequence of the columns is the same as that of sub-elements entry.  In total, there are three basic types of entries:\nConstant Every quoted entry is defined as a constant. The content inside the quotation will be directly written into each corresponding interaction record.\n\u0026lt;entry\u0026gt;\u0026quot;UPDATE_VEHICLE\u0026quot;\u0026lt;/entry\u0026gt;  An example for constant type entry\nBasic method The Basic method type accesses values of the interaction object by using the appropriate getXXX() methods. For an entry, the root object for method invoking is the corresponding interaction class, here VehicleUpdates. As this object provides the simulation time by calling the getter method getTime(), the entry Time retrieves the requested value. If a null object is returned before the last method of cascaded methods is invoked, then null will be written to the corresponding field.\n\u0026lt;entry\u0026gt;Time\u0026lt;/entry\u0026gt;  An example for constant type entry\nIteration \u0026lt;entry\u0026gt;Updated:Id\u0026lt;/entry\u0026gt;  An example for method type entry with iteration\nThe first part of this example is Updated , which means to invoke the getUpdated method of class VehicleUpdates. Then a list of VehicleInfo objects is returned. The character : indicates the iteration, which means that for each of the VehicleInfo objects in the returned list the getId method is invoked.\nCascading \u0026lt;entry\u0026gt;Updated:Position.Latitude\u0026lt;/entry\u0026gt;  An example for method type entry with iteration and cascading\nIn this example, there is a dot operation, which is a cascade operation. Here getPosition method of VehicleInfo class is called and a GlobalPosition object is returned. Then we continuously invoke the getLatitude method of this GlobalPosition object.\nExtended Method All the methods involved above are the basic methods. There also is some functionality, which we cannot extract from these existing methods. So an extended method set is offered to meet these requirements and also as an extension point in the future.\n\u0026lt;entry\u0026gt;TimeInSec\u0026lt;/entry\u0026gt;  An example for simple extended method type entry\nWith existing methods of VehicleUpdates and its super class Interaction, we cannot get the timestamp of a interaction in second. (only Interaction.getTime, which returns a time in ns, is available). Here, getTimeInSec is a method extension for Interaction class. The extended method set will be listed later.\nFurther details The method type of entry definition supports cascaded iteration as follows:\n\u0026lt;entry\u0026gt;List1:List2:Id\u0026lt;/entry\u0026gt;  An example for cascaded iteration\nIt is possible to handle several different iterating operations, coming from the entry definition:\n\u0026lt;entry\u0026gt;Senders:Id\u0026lt;/entry\u0026gt; \u0026lt;entry\u0026gt;Receivers:Id\u0026lt;/entry\u0026gt;  An example for multi-level iteration\ngetSenders() and getReceivers() are two different iterations. In this case, a combination of both Ids from the lists will be generated. The result may look like this:\nsender1, receiver1 sender1, receiver2 sender2, receiver1 sender2, receiver2  Output result of the above listing\nNote: the longest matched prefix will be considered as the same iterating operation, which means they are in the same level of iteration structure.\nAdditional features Limit output on time frame You can configure the File Output Generator to write out interactions within a specific frame of simulation time. This can be configured by setting the start and end attributes accordingly:\n\u0026lt;?xml version=\u0026quot;1.0\u0026quot; encoding=\u0026quot;UTF-8\u0026quot;?\u0026gt; \u0026lt;output id=\u0026quot;fileoutput\u0026quot; enabled=\u0026quot;true\u0026quot; start=\u0026quot;300\u0026quot; end=\u0026quot;1000\u0026quot; update=\u0026quot;5\u0026quot; loader=\u0026quot;org.eclipse.mosaic.fed.output.generator.file.FileOutputLoader\u0026quot;\u0026gt; ... \u0026lt;/output\u0026gt;  An example for restricting output generation of interactions within a time frame\nCompress Output The tag \u0026lt;write\u0026gt;file+compress\u0026lt;/write\u0026gt; can be added to the output configuration, in order to compress the output using gzip compression. This feature is suitable for large-scale scenarios with many outputs.\n\u0026lt;output id=\u0026quot;output\u0026quot; loader=\u0026quot;org.eclipse.mosaic.fed.output.generator.file.FileOutputLoader\u0026quot;\u0026gt; \u0026lt;write\u0026gt;file+compress\u0026lt;/write\u0026gt; ... \u0026lt;/output\u0026gt;  ","date":1557010800,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1557010800,"objectID":"8a0ce6620232f8de93a82bc2989cf5de","permalink":"https://www.eclipse.org/mosaic/docs/visualization/filevis/","publishdate":"2019-05-05T00:00:00+01:00","relpermalink":"/mosaic/docs/visualization/filevis/","section":"docs","summary":"The File Output Generator is a tool which gives you the opportunity to log specific Eclipse MOSAIC interaction types. For each interaction the File Output receives, one line (or more in case of an iteration object) is added to a CSV output file.","tags":null,"title":"File Output Generator","type":"docs"},{"authors":null,"categories":null,"content":"This section presents the architecture and the main features of the Application Simulator as well as the related Mapping Ambassador, which is used to configure individual simulation entities (or simulation units) and \u0026ldquo;map\u0026rdquo; applications to them.\nEclipse 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.\nFolder Structure └─ \u0026lt;scenario_name\u0026gt; ├─ application | ├─ YourApplication.jar | ├─ application_config.json ............. Configuration file for the ambassador. | └─ \u0026lt;scenario_name\u0026gt;.db .................. Database file for navigation. └─ mapping └─ mapping_config.json ................. Configuration file for the ambassador.  This ambassador can be configured with a configuration file. The specific path is \u0026lt;scenario_name\u0026gt;/application/application_config.json. However, it is not necessary to provide such file.\nInstallation This simulator does not need to be installed. It is delivered as part of the Eclipse MOSAIC installation package.\nOverview 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.\n  Overview of interaction between applications and the unit\u0026rsquo;s operating system with its modules. An example V2X message propagation is presented.   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).\nAs 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.\nThe following table lists all modules a unit\u0026rsquo;s operating system could provide.\n   Module Description     NavigationModule Full featured access to the central navigation component for vehicles   RoutingModule Access to routing functionalities for static units as RSUs   AdHocModule Communication via ad hoc mode, using WIFI or ITS G5 specific means (e.g. for addressing)   CellModule Communication via cellular services (different configuration / addressing modes)     Note: The presented communication modules AdHocModule, CellModule are used for the sending part of a transmission. The message reception is realized by Application Interfaces provided by the CommunicationApplication.\n Application Interfaces Application interfaces handle call-backs to incoming events via their methods, like onVehicleUpdated(), called by the application simulator. The following table lists all interfaces usable for application implementation, the type of unit as well as important other interfaces it implements. Interface specific public methods which have to be implemented by the user are listed in the \u0026ldquo;Provides\u0026rdquo; column. The elementary interface (Application) provides the methods onStartup(), onShutdown(). Implementation details are given in Development of applications  .\n   Interface Applicable to Provides Description     Application / AbstractApplication all onStartup, onShutdown Elementary application class providing an operating system   ConfigurableApplication all  Basic application class providing an operating system and a configuration, which automatically loaded from a JSON file.   CommunicationApplication all onMessageReceived, onAcknowledgementReceived, onCamBuilding, onMessageTransmitted All applications that implement some form of V2X communication are to implement this interface.   VehicleApplication vehicle onVehicleUpdated General vehicle funtionality   ElectricVehicleApplication vehicle onBatteryStateUpdated, onChargingRequestRejected Electric vehicle functionality   TrafficSignAwareApplication vehicle onTrafficSignInvalidated, onTrafficSignNoticed Used by vehicles which are aware of traffic signs.   TrafficLightApplication traffic light onTrafficLightGroupUpdated Traffic light functionality   TrafficManagementCenterApplication TMC onInductionLoopUpdated, onLaneAreaDetectorUpdated Traffic management functionality   MosaicApplication all onSumoTraciResponded, onInteractionReceived Features that involve customized RTI-interactions of MOSAIC    Note: A roadside unit (RSU) is the most unit and usually communicates only. Thus, an RSU application implements CommunicationApplication.\n Configuration The Application simulator is configured in the file \u0026lt;scenario_name\u0026gt;/application/application_config.json:\n{ \u0026quot;messageCacheTime\u0026quot;: \u0026quot;30s\u0026quot;, \u0026quot;minimalPayloadLength\u0026quot;: 200, \u0026quot;encodePayloads\u0026quot;: true, \u0026quot;navigationConfiguration\u0026quot; : { \u0026quot;type\u0026quot;: \u0026quot;database\u0026quot; } }  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).\n Eclipse MOSAIC Mapping Closely related to the Application Simulator, the Mapping Ambassador is used for the initial choreography of a simulation. It defines two major aspects for the simulation units:\n number, properties, position (e.g. of RSUs, traffic lights) or initial routes (of vehicles, simulated in a traffic/vehicle simulator) specific application(s) to be \u0026ldquo;mapped\u0026rdquo; on the simulation units and simulated in the Application Simulation  The JSON based configuration is located in \u0026lt;scenario_name\u0026gt;/mapping/mapping_config.json.\nConfiguration The Mapping configuration is divided into different parts:\n Pre Definitions of prototypes and deviations Entity Definitions of vehicles, rsus, tls servers and tmcs Advanced Vehicle Definitions (including route generation) in matrixMappers Common Definitions in config  Prototypes prototypes define models for other objects, which can be reused later in the other sections of the Mapping. This allows reusing the definition of certain entities such as vehicles or the combination of multiple applications, reducing redundancies and resulting in shorter Mapping configurations.\n\u0026quot;prototypes\u0026quot;: [ { \u0026quot;name\u0026quot;: \u0026quot;CamVehicle\u0026quot;, \u0026quot;accel\u0026quot;: 2.6, \u0026quot;decel\u0026quot;: 4.5, \u0026quot;length\u0026quot;: 5.00, \u0026quot;maxSpeed\u0026quot;: 70.0, \u0026quot;applications\u0026quot;: [ \u0026quot;org.eclipse.mosaic.fed.application.app.etsi.VehicleCamSendingApp\u0026quot; ] } ]  Prototypes can be created for all types of entities. Next to the list of applications which is available for all types of entities, vehicle types provide various other parameters to be adjusted.\n   Parameter Description Deviation     vehicleClass The class of the vehicle, e.g. Car, ElectricVehicle, EmergencyVehicle, Bicycle, HeavyGoodsVehicle, and more.    accel The maximum acceleration of the vehicle in $m/s^2$. Yes   decel The maximum deceleration of the vehicle in $m/s^2$, e.g. when stopping for traffic lights. Yes   emergencyDecel The maximum deceleration of the vehicle in $m/s^2$, in order to avoid accidents.    length The length of the vehicle in $m$. Yes   maxSpeed The maximum speed of the vehicle in $m/s$. Yes   minGap The minimum gap towards the leader in $m$, i.e. the space in front in a traffic jam. Yes   sigma The driver\u0026rsquo;s imperfection $[0,1]$.    tau The reaction time (or time headway) of the vehicle in $s$. Yes   speedFactor This factor is used to determine the speed limit to comply on roads, e.g. 1.1 would exceed the speed limit by 10%. Yes   laneChangeMode The lane changing behavior of the vehicle: COOPERATIVE. CAUTIOUS, AGGRESSIVE, PASSIVE, OFF    applications The list of applications to map onto this vehicle type.     For the majority of the parameters above (see column \u0026ldquo;Deviation\u0026rdquo;), a normal distribution can be created. In that case, each individual vehicle spawned with this prototype will be loaded with a random value within this distribution. To achieve this, a separate deviations attribute must be added to the type:\n\u0026quot;prototypes\u0026quot;: [ { \u0026quot;name\u0026quot;: \u0026quot;Car\u0026quot;, \u0026quot;length\u0026quot;: 5.0, \u0026quot;maxSpeed\u0026quot;: 70.0, \u0026quot;deviations\u0026quot;: { \u0026quot;length\u0026quot;: 1.2, \u0026quot;maxSpeed\u0026quot;: 5.0 } } ]  According to the config above, the basic parameter value conforms to the expected value, and the given value in the deviations attribute conforms to the $\\sigma$ of the Gaussian distribution(meaning for the example of maxSpeed that ~68% of the values will be located in the interval [65.0, 75.0]). The deviation will be limited to ±2$\\sigma$.\nEntities Vehicles\nThe vehicles-section is the centerpiece of the Mapping configuration. It defines the departures (times and number), routes, and types of the vehicles.\nEach spawner in this list generates a traffic stream of vehicles on a certain route. The vehicles stream begins at startingTime and generates vehicles until maxNumberVehicles is reached. The time between two consecutively vehicles is implicitly given by the targetFlow property, which defines how many vehicles per hour are going to be spawned.\nEach vehicle spawner must refer to at least one vehicle type (types). A vehicle type must either refer to a type from the prototypes section by using its name, or be defined as a completely new vehicle type with all necessary parameters. If more than one vehicle type is referenced in the types attribute, weights can be used to specify the ratios to choose between them when loading an individual vehicle. If no weights are defined, individual vehicle types are assumed to be distributed equally.\n Note: if at least one vehicle type has a weight defined, all types without a defined weight are ignored.\n \u0026quot;vehicles\u0026quot;: [ { \u0026quot;startingTime\u0026quot;: 5.0, \u0026quot;targetFlow\u0026quot;: 1800, \u0026quot;maxNumberVehicles\u0026quot;: 120, \u0026quot;route\u0026quot;: \u0026quot;1\u0026quot;, \u0026quot;types\u0026quot;: [ { \u0026quot;name\u0026quot;: \u0026quot;CAMVehicle\u0026quot;, \u0026quot;weight\u0026quot;: 0.1 }, { \u0026quot;name\u0026quot;: \u0026quot;NormalVehicle\u0026quot;, // this vehicle has no applications \u0026quot;applications\u0026quot;: [ ], \u0026quot;weight\u0026quot;: 0.2 } ] } ]  Additional notes:\n The route refers to a route usually defined in the scenario database file (*.db) of the scenario. In order to define only one single vehicle to be spawned, the maxNumberVehicles property can be set to 1. By defining the endingTime property, the flow is stopped from being generated when the given simulation time is reached. By defining the spawningMode to one of the following values, the departure time of the individual vehicles can be adjusted:  CONSTANT - default case, all vehicles have equal time distance to match target_flow. POISSON - vehicles depart within a Poisson distribution, resulting in a more natural traffic flow. GROW - the flow of departing vehicles increases linear up to target_flow. SHRINK - the flow of departing vehicles decreases linear starting at target_flow. GROW_AND_SHRINK - the flow of departing vehicles increases up to target_flow and decreases afterwards.   By defining the laneSelectionMode to one the following values, the selection of the departure lane can be adjusted:  DEFAULT - selects the lane for the next vehicle based on the list of given lanes in a roundrobin manner. ROUNDROBIN_HIGHWAY - trucks will be spawned on the rightmost lane, all other vehicles according to DEFAULT. HIGHWAY - trucks will be spawned on the rightmost lane, all other vehicles according to BEST. RANDOM - the vehicle will be placed randomly on one of the available lanes of the road. FREE - the vehicle will be placed on a free lane of the road. BEST - the vehicle will be placed on the best lane of the road, according to the current traffic situation and departure speed.    Road Side Units\nThe rsus-section offers the possibility to define instances of application supported Road Side Units (RSU)s and place them on a defined position (lat, lon coordinates). Referring to prototype definitions with simply specifying its name in the name property will automatically fill in relevant properties of the RSU.\n\u0026quot;rsus\u0026quot;: [ { \u0026quot;lat\u0026quot;: 52.65027, \u0026quot;lon\u0026quot;: 13.54500, \u0026quot;name\u0026quot;: \u0026quot;WeatherServer\u0026quot;, \u0026quot;applications\u0026quot;: [ \u0026quot;org.eclipse.mosaic.app.tutorial.WeatherServerApp\u0026quot; ] } ]  Traffic Lights\nIn the trafficLights-section, applications can be mapped to traffic light groups. Usually, individual traffic lights are part of traffic light groups to control a whole junction, whereas the junction possesses a certain position. The traffic light groups and their positions are defined in the simulator specific configuration file (e.g. the *.net.xml for SUMO and *.ttl.json for PHABMACS). The tlGroupId-property allows mapping of applications to the traffic light groups, referring them by Id.\nAlternatively, the definition of the weight-property leads to a random distribution of the referred applications through ALL traffic lights of the scenario (Note: The weights do not have to add up to 100 or 1). Consequently, all traffic lights will be mapped using the specified prototypes as soon as one weight differs from zero. So in case you don’t want all traffic lights to have applications running on them you have to define one traffic light without any applications and add a weight to it. If neither tlGroupId nor weight are defined for an app, the weight will be set to 1.\n\u0026quot;trafficLights\u0026quot;: [ { \u0026quot;tlGroupId\u0026quot;: \u0026quot;26704448\u0026quot;, \u0026quot;applications\u0026quot;: [ \u0026quot;org.eclipse.mosaic.app.tutorial.TrafficLightApp\u0026quot; ] }, { \u0026quot;tlGroupId\u0026quot;: \u0026quot;252864802\u0026quot;, \u0026quot;applications\u0026quot;: [ \u0026quot;org.eclipse.mosaic.app.tutorial.TrafficLightApp\u0026quot; ] } ]  For more information, explained for detailed examples with different mapping options regarding traffic lights, please refer to Simulation Scenarios - Traffic Lights  .\nServers\nThe servers-array can be used to specify server units, which can be used to communicate with other units via the cell module. Capacity configurations for servers should be done when enabling the CellModule. Delay and transmission models are configured in the network.json of the cell module (see here  ).\n Note: The group parameter in the mapping configuration has to match with the id in the network configuration in order to properly function.\n \u0026quot;servers\u0026quot;: [ { \u0026quot;name\u0026quot;: \u0026quot;MyServer\u0026quot;, \u0026quot;group\u0026quot;: \u0026quot;TestServers\u0026quot;, \u0026quot;applications\u0026quot;: [ \u0026quot;ServerApp1\u0026quot;, \u0026quot;ServerApp2\u0026quot; ] } ]  Traffic Management Centers\nThe tmc-section offers the possibility to define instances of a Traffic Management Center (TMC). A TMC provides the possibility to interact with the infrastructure of the road, i.e. retrieving traffic properties from detectors (e.g. traffic flow), and changing properties from the road (e.g. speed limits). Additionally, TMCs are an extension of Servers and can be configured in the same way that servers are\n\u0026quot;tmcs\u0026quot;: [ { \u0026quot;name\u0026quot;: \u0026quot;HighwayManagement\u0026quot;, \u0026quot;group\u0026quot;: \u0026quot;TestTmcServers\u0026quot;, \u0026quot;applications\u0026quot;: [ \u0026quot;com.dcaiti.vsimrti.app.tutorials.highway.HighwayManagementApp()\u0026quot; ], \u0026quot;inductionLoops\u0026quot;: [ \u0026quot;detector_0\u0026quot;, \u0026quot;detector_1\u0026quot;, \u0026quot;detector_2\u0026quot; ], \u0026quot;laneAreaDetectors\u0026quot;: [ ] } ]   All unit spawners could be realized in two different ways. The Deterministic Mapping produces the exact same sequence of mapped vehicles in every simulation run with regard to the given ratios at each point in time the simulation). The Stochastic Mapping results in a random order of mapped units.\n Use Type Distributions in Complex Traffic Scenarios In the case, you have many vehicle spawners defined and you want to distribute prototypes on those vehicles equally without defining them again and again, you can use typeDistributions. By doing so, it is very simple to adjust the list of types and weights at only one place in the configuration file.\nInstead of defining an equal list of types and weights for each single vehicle spawner, like in this example:\n\u0026quot;vehicles\u0026quot;: [ { \u0026quot;startingTime\u0026quot;: 5.0, \u0026quot;targetFlow\u0026quot;: 1800, \u0026quot;maxNumberVehicles\u0026quot;: 120, \u0026quot;route\u0026quot;: \u0026quot;1\u0026quot;, \u0026quot;types\u0026quot;: [ { \u0026quot;name\u0026quot;: \u0026quot;TypeA\u0026quot;, \u0026quot;weight\u0026quot;: 0.1 }, { \u0026quot;name\u0026quot;: \u0026quot;TypeB\u0026quot;, \u0026quot;weight\u0026quot;: 0.9 } ] }, { \u0026quot;startingTime\u0026quot;: 55.0, \u0026quot;targetFlow\u0026quot;: 1800, \u0026quot;maxNumberVehicles\u0026quot;: 120, \u0026quot;route\u0026quot;: \u0026quot;2\u0026quot;, \u0026quot;types\u0026quot;: [ { \u0026quot;name\u0026quot;: \u0026quot;TypeA\u0026quot;, \u0026quot;weight\u0026quot;: 0.1 }, { \u0026quot;name\u0026quot;: \u0026quot;TypeB\u0026quot;, \u0026quot;weight\u0026quot;: 0.9 } ] } ]  \u0026hellip; you can use typeDistributions to define the distribution of types for each vehicle once and reuse them:\n\u0026quot;typeDistributions\u0026quot;: { \u0026quot;exampleTypeDist\u0026quot; : [ { \u0026quot;name\u0026quot;: \u0026quot;TypeA\u0026quot;, \u0026quot;weight\u0026quot;: 0.1 }, { \u0026quot;name\u0026quot;: \u0026quot;TypeB\u0026quot;, \u0026quot;weight\u0026quot;: 0.9 } ] }, \u0026quot;vehicles\u0026quot;: [ { \u0026quot;startingTime\u0026quot;: 5.0, \u0026quot;targetFlow\u0026quot;: 1800, \u0026quot;maxNumberVehicles\u0026quot;: 120, \u0026quot;route\u0026quot;: \u0026quot;1\u0026quot;, \u0026quot;typeDistribution\u0026quot;: \u0026quot;exampleTypeDist\u0026quot; }, { \u0026quot;startingTime\u0026quot;: 55.0, \u0026quot;targetFlow\u0026quot;: 1800, \u0026quot;maxNumberVehicles\u0026quot;: 120, \u0026quot;route\u0026quot;: \u0026quot;2\u0026quot;, \u0026quot;typeDistribution\u0026quot;: \u0026quot;exampleTypeDist\u0026quot; } ]  Advanced vehicle spawners with route generation It is also possible to define and use OD (origin-destination) matrices by adding a ODMatrixMapper to the matrixMappers-list. Each MatrixMapper consists of a list of points, the vehicle-types to be used and the actual flow-values (odValues) between each of the points. It is possible to define multiple matrices. This way can achieve distinctively different compositions of the vehicle flows.\nThe MatrixMapper will be called before the actual execution of the simulation and will generate vehicle-spawners for the flow between each of the points.\n\u0026quot;matrixMappers\u0026quot;: [ { \u0026quot;points\u0026quot;: [ { \u0026quot;name\u0026quot;: \u0026quot;CityA\u0026quot;, \u0026quot;position\u0026quot;: { \u0026quot;center\u0026quot;: { \u0026quot;latitude\u0026quot;: 52, \u0026quot;longitude\u0026quot;: 13 }, \u0026quot;radius\u0026quot;: 1000 } }, { \u0026quot;name\u0026quot;: \u0026quot;CityB\u0026quot;, \u0026quot;position\u0026quot;: { \u0026quot;center\u0026quot;: { \u0026quot;latitude\u0026quot;: 48, \u0026quot;longitude\u0026quot;: 10 }, \u0026quot;radius\u0026quot;: 1000 } } ], \u0026quot;types\u0026quot;: [ { \u0026quot;name\u0026quot;: \u0026quot;CAMVehicle\u0026quot; } ], \u0026quot;odValues\u0026quot;: [ [0, 100], //100 vehicles from CityA to CityB [200, 0] //200 vehicles from CityB to CityA ] } ]  Common Configuration Next to the specific configuration of prototypes and simulation entities, some general parameters can be adjusted:\n{ \u0026quot;config\u0026quot;: { \u0026quot;scaleTraffic\u0026quot; : 1.0, \u0026quot;start\u0026quot;: 0, \u0026quot;end\u0026quot;: 500, \u0026quot;adjustStartingTimes\u0026quot;: false, \u0026quot;randomizeFlows\u0026quot;: false, \u0026quot;randomizeStartingTimes\u0026quot; : false, \u0026quot;randomizeWeights\u0026quot;: false } }     Parameter Description     scaleTraffic Scales the targetFlow of spawned vehicles per hour as well as the maxNumberVehicles by the given factor.   start Adjusts the point in time (in $s$) to start spawning vehicles. Any vehicle spawner with a lower startingTime will be ignored.   end Adjusts the point in time (in $s$) to end spawning vehicles. Any vehicle spawner with a greater startingTime will be ignored.   adjustStartingTimes If set to true, the starting time of each spawner is reduced by the value in start.   randomizeFlows If set to true, the departure time of vehicles within a vehicle spawner is slightly randomized.   randomizeStartingTimes If set to true, the starting time of each vehicle spawner is slightly randomized.   randomizeWeights If set to true, each weight greater than zero is slightly randomized.     Read the detailed documentation of the Mapping Configuration.\n  Unit Identifiers Every traffic object in Eclipse MOSAIC has a globally unique string identifier. These identifiers are used to identify a traffic object in Eclipse MOSAIC as well as in different ambassadors. From user’s aspect, these identifiers will be seen in the log files which are generated after a simulation. The following table explains, which identifier belongs to which traffic object.\n   Traffic Object Eclipse MOSAIC Internal ID     Vehicle veh_\u0026lt;seq_nr\u0026gt;   RSU rsu_\u0026lt;seq_nr\u0026gt;   TMC tmc_\u0026lt;seq_nr\u0026gt;   Traffic Light tl_\u0026lt;group_id\u0026gt;     seq_nr is the sequence number of simulated vehicles, RSUs, TMCs, each starting from zero. group_id is the group id of the traffic light.   ##Basic Applications\nEclipse 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.\nAdditionally, 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:\nETSI 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.\nCurrently, the default configuration (ETSIApplication.json) for the ETSI application looks like this:\n{ /* The maximum time offset (here 1 second) of sending CA-messages * (the offset will be different for every single vehicle to avoid interference) */ \u0026quot;maxStartOffset\u0026quot;: 1000000000, /* CAMs are sent at most every 1 second */ \u0026quot;minInterval\u0026quot;: 100000000, /* CAMs are sent at least every 1 second */ \u0026quot;maxInterval\u0026quot;: 1000000000, /* CAMs are sent when the position of the vehicle changes at least about 4 meters */ \u0026quot;positionChange\u0026quot;: 4, /* CAMs are sent when the heading of the vehicle changes at least about 4 degrees */ \u0026quot;headingChange\u0026quot;: 4, /* CAMs are sent when the velocity of the vehicle changes at least about 0.5 m/s */ \u0026quot;velocityChange\u0026quot;: 0.5 }  The CAMs sent out by this application consist of four parts:\n 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.\n","date":1557010800,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1557010800,"objectID":"bf25e52bde5c4e80a5aa654a38a7b644","permalink":"https://www.eclipse.org/mosaic/docs/simulators/application_simulator/","publishdate":"2019-05-05T00:00:00+01:00","relpermalink":"/mosaic/docs/simulators/application_simulator/","section":"docs","summary":"This section presents the architecture and the main features of the Application Simulator as well as the related Mapping Ambassador, which is used to configure individual simulation entities (or simulation units) and \u0026ldquo;map\u0026rdquo; applications to them.","tags":null,"title":"Application Simulator","type":"docs"},{"authors":null,"categories":null,"content":"To run a single simulation via Command Line Interface (CLI), call the Eclipse MOSAIC start script with the following command line arguments.\nGNU/Linux ./mosaic.sh -s \u0026lt;scenario-name\u0026gt; ./mosaic.sh -c ./scenarios/\u0026lt;scenario_name\u0026gt;/scenario_config.json  Windows mosaic.bat -s \u0026lt;scenario-name\u0026gt; mosaic.bat -c .\\scenarios\\\u0026lt;scenario_name\u0026gt;\\scenario_config.json  Example The following call starts the example scenario \u0026ldquo;Barnim\u0026rdquo; in Eclipse MOSAIC on a Windows machine and opens a Visualization in your browser  :\nmosaic.bat -s Barnim -v   Running the pre-bundled example scenario \u0026ldquo;Barnim\u0026rdquo; with Eclipse MOSAIC   CLI Options The Eclipse MOSAIC start script supports the following arguments:\n table th:first-of-type { width: 20%; } table th:nth-of-type(2) { width: 80%; }     Option Description     -c\n--configuration The primary configuration file which is scenario dependent and located in the according scenario folder. This file transitively includes other necessary configuration files. Usually you will use the file \u0026lt;mosaic-root\u0026gt;/scenarios/\u0026lt;scenario_name\u0026gt;/scenario_config.json.   -s\n--scenario If the main configuration file of your scenario is located in the default scenario directory of MOSAIC (i.e. in \u0026lt;mosaic-root\u0026gt;/scenarios/\u0026lt;scenario_name\u0026gt;/scenario_config.json), this option can be used instead of the -c option by passing only the scenario name -s \u0026lt;scenario_name\u0026gt;.   -w\n--watchdog-interval The interval of the internal alive check (in seconds) which is used by MOSAIC to detect execution stalls. This parameter is not mandatory and it is also possible to turn off the watchdog (-w 0) for debug sessions.   -o\n--log-level Override all specified logging-levels. This option is useful for debugging simulations. For example logging every possible event would be done with -o TRACE.   -b\n--realtime-brake With this parameter, the simulation will be slowed down to a desired Real Time Factor, if possible. When simulations already run slower than real time, this factor will have no effect. For example, use -b 1 to execute the simulation in real time.   -r\n--random-seed The global random seed to set for the simulation run. This is usually defined in the scenario_config.json, but can be overridden using this option.   -v\n--start-visualizer Opens a page in your default browser which visualizes all vehicle movements of the simulation on a map. This option only works, if your scenario is configured with the Websocket Visualizer  .   -h\n--help Prints a help screen.    While Eclipse MOSAIC is running, it prints some information on the command line:\n[user@gnulinux mosaic]$ ./mosaic.sh -s HelloWorld 2020-09-08 16:46:09,794 INFO ROOT - Running Eclipse MOSAIC 20.0 on Java JRE v1.8.0_202 (AdoptOpenJdk) 2020-09-08 16:46:09,941 INFO FederationManagement - Start federation with id 'HelloWorld' 2020-09-08 16:46:09,943 INFO FederationManagement - Add ambassador/federate with id 'application' 2020-09-08 16:46:09,944 INFO FederationManagement - Add ambassador/federate with id 'mapping' 2020-09-08 16:46:09,945 INFO FederationManagement - Add ambassador/federate with id 'sumo' 2020-09-08 16:46:09,946 INFO FederationManagement - Deploying federate 'sumo' locally in .\\tmp\\sumo 2020-09-08 16:46:09,962 INFO FederationManagement - Starting federate 'sumo' locally in .\\tmp\\sumo 16:46:17 - Simulating: 195000000000ns (195.0s / 1000.0s) - 19.5% (RTF:33.10, ETC:25.2s)  The current simulation progress is shown in the following format.\n current wall clock time current simulation time in [ns] and [s] progress in % Real Time Factor (RTF) and Estimated Time to Completion (ETC)  The RTF is the ratio of simulated time to simulation duration in wall clock time, e.g. a real time factor greater than 1.0 means, the simulation is running faster than real time. Both RTF and ETC are calculated based on the performance of the last five seconds of the simulation and should only give a rough overview, how long a simulation can take. Depending on the simulation setup, the values can differ heavily between start and end of a simulation.\nGather results All active simulators as well as the according ambassadors generate certain logging output, depending on their configured logging level. Therefore, these logs are very helpful to retrace and understand the individual states during the simulation time. The generated log files can be found in the \u0026lt;mosaic-root\u0026gt;/logs/log-\u0026lt;timestamp\u0026gt; directory.\nMoreover, Eclipse MOSAIC offers uniformly formatted and visually prepared results using various  Output Generator   implementations. For example, the FileOutputGenerator generates detailed outputs of e.g. vehicle positions, speeds, or message exchanges. In the scenarios brought by the latest release, this output mechanism is already configured.\nScenario Configuration The configuration of a simulation scenario consists of a detailed description for each coupled simulator. The main configuration file is found under scenario_config.json, which defines the list of coupled simulators:\n{ \u0026quot;simulation\u0026quot;: { \u0026quot;id\u0026quot;: \u0026quot;Barnim\u0026quot;, \u0026quot;duration\u0026quot;: \u0026quot;1000s\u0026quot;, \u0026quot;randomSeed\u0026quot;: 268965854, \u0026quot;projection\u0026quot;: { \u0026quot;centerCoordinates\u0026quot;: { \u0026quot;latitude\u0026quot;: 52.511289, \u0026quot;longitude\u0026quot;: 13.3167457 }, \u0026quot;cartesianOffset\u0026quot;: { \u0026quot;x\u0026quot;: -385769.05, \u0026quot;y\u0026quot;: -5819239.29 } } }, \u0026quot;federates\u0026quot;: { \u0026quot;application\u0026quot;: true, \u0026quot;environment\u0026quot;: false, \u0026quot;cell\u0026quot;: false, \u0026quot;ns3\u0026quot;: false, \u0026quot;omnetpp\u0026quot;: false, \u0026quot;sns\u0026quot;: false, \u0026quot;sumo\u0026quot;: true, \u0026quot;visualizer\u0026quot;: true } }  This way, simulators can be easily added or removed from the simulation. Each of the coupled simulators is configured in the directory of the scenario_config.json file. The release bundle comes with a set of tutorial scenarios, which are described in detail in the Tutorials section  .\n","date":1557010800,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1557010800,"objectID":"c60b5956ddd6a163875c0dc191dc8c6e","permalink":"https://www.eclipse.org/mosaic/docs/getting_started/run_mosaic/","publishdate":"2019-05-05T00:00:00+01:00","relpermalink":"/mosaic/docs/getting_started/run_mosaic/","section":"docs","summary":"To run a single simulation via Command Line Interface (CLI), call the Eclipse MOSAIC start script with the following command line arguments.\nGNU/Linux ./mosaic.sh -s \u0026lt;scenario-name\u0026gt; ./mosaic.sh -c ./scenarios/\u0026lt;scenario_name\u0026gt;/scenario_config.json  Windows mosaic.","tags":null,"title":"Run a simulation with Eclipse MOSAIC","type":"docs"},{"authors":null,"categories":null,"content":"  The tool scenario-convert is part of MOSAIC Extended.\nHowever, you can use scenario-convert for free to generate scenarios which are executable with Eclipse MOSAIC. Get it here.\n  Download scenario-convert from DCAITI mirror  scenario-convert is a useful tool, which can be used to create new scenarios or import and export data from external sources like OpenStreetMap, SUMO etc into your existing scenarios.\nIt will create a database, which is the basis for all map-related tasks performed by Eclipse MOSAIC (e.g. navigation, route calculation\u0026hellip;).\nBased on a MOSAIC database, scenario-convert can export the data to SUMO-conform formats. Furthermore one can choose, whether to use routes generated by scenario-convert, use existing routes or build own routes via route generation tools (e.g. DUAROUTER by SUMO).\nThis chapter intends to highlight the most common workflows for the work with scenario-convert. We will be using steglitz.osm  OSM-file for most of the use cases So feel free to follow along with the steps to get a better understanding on how the scenario-convert-script functions.\n Here you can find a complete reference to all options scenario-convert offers.\n   OSM-File of Steglitz   Creating a complete Eclipse MOSAIC-scenario from an OSM-file with one command This is the most straight forward way to create a scenario from your OSM-file. We will use the option --osm2mosaic, which is a combination of the options --osm2db and --db2mosaic.\nLet\u0026rsquo;s start off by showing you how a complete call could look like:\njava -jar scenario-convert.jar --osm2mosaic -i steglitz.osm   In this section we use the scenario name steglitz. as synonym for path/to/steglitz..\n  This achieves a couple of things. First off the script is going to create a SQLite-database, which is used by Eclipse MOSAIC. Furthermore, a directory will be created, which should look like this:\n└─ \u0026lt;working-directory\u0026gt; └─ steglitz ├─ steglitz.osm ├─ application | └─ steglitz.db ├─ cell | ├─ cell_config.json | ├─ network.json | └─ regions.json ├─ environment | └─ environment_config.json ├─ mapping | └─ mapping_config.json ├─ ns3 | ├─ ns3_config.json | └─ ns3_federate_config.xml ├─ omnetpp | ├─ omnetpp_config.json | └─ omnetpp.ini ├─ output | └─ output_config.xml ├─ sns | └─ sns_config.json ├─ sumo | ├─ steglitz.net.xml | └─ steglitz.sumocfg └─ scenario_config.json .................. Basic configuration of the simulation scenario  Let\u0026rsquo;s walk through all these files:\n First the steglitz.db will be created using the steglitz.osm-file. The steglitz.db will be used to create steglitz.con.xml, steglitz.edg.xml and steglitz.nod.xml, which are files used by SUMO.  SUMO Netconvert  is used to create steglitz.net.xml, which is a network representation  in SUMO. Now the SUMO-configuration steglitz.sumo.cfg is written. Afterwards the mapping_config.json and scenario_config.json are created and all files are moved to the right place. In the scenario_config.json values like the center coordinate will automatically be set using data from the SUMO related files.  While this is technically sufficient to start working on your scenario there are a couple of other things you can do to achieve better results.\nClean the OSM-file using Osmosis\nOsmosis will automatically be used to create a new OSM-file with the suffix _cleaned. The created file will contain much less clutter and usually is better suited for simulation purposes. Check the images below to see the difference the clean-up process can make.\njava -jar scenario-convert.jar --osm2mosaic -i steglitz.osm   Uncleaned OSM-file     Cleaned OSM-file      Uncleaned Net-file     Cleaned Net-file     To avoid \u0026ldquo;cleaning\u0026rdquo; the OSM-file, please use the option \u0026ldquo;skip-osm-filter\u0026rdquo;.\njava -jar scenario-convert.jar --osm2mosaic -i steglitz.osm --skip-osm-filter  Generating Routes\nThe scenario-convert also offers the option --generate-routes, which will generate a route-file, given some additional information. For example purposes we will run the following command:\njava -jar scenario-convert.jar --osm2mosaic -i steglitz.osm --generate-routes --route-begin-latlon 52.4551693,13.3193474 --route-end-latlon 52.4643101,13.3206834 --number-of-routes 3  This will calculate three routes between the two given coordinates.\nAlternatively you can use the following command in order to generate routes with node-id\u0026rsquo;s as start and end point, which can be found in the steglitz.nod.xml file.\njava -jar scenario-convert.jar --osm2mosaic -i steglitz.osm -o --generate-routes --route-begin-node-id 267350668 --route-end-node-id 313139970 --number-of-routes 3  See below  for all command line options.\nConlusion\nThis wraps up one of the main workflows with the scenario-convert-script. A quick reminder on what we achieved:\n Cleaned up an OSM-file to only contain relevant data. Converted that OSM-file to formats that Eclipse MOSAIC/SUMO can handle. Created the project structure for a scenario. Calculated routes between two coordinates.  With all of this you can now start further developing your scenario. For a more detailed description on the next steps please have a look here (Simulation Scenarios)  and here (Application Development)  .\nWhile this is the \u0026lsquo;happy world\u0026rsquo; workflow it is often necessary to manually adapt routes and insert them into your scenario. The following workflow will explain how that is done and you will also get a more detailed overview of the scenario-convert-functions.\nImporting Routes to your scenario As mentioned above your routes won\u0026rsquo;t always be created by the scenario-convert script. We generated some routes for the steglitz-scenario using SUMO\u0026rsquo;s duarouter  , which you can find here  . We\u0026rsquo;ll start with only the steglitz.osm and steglitz.rou.xml files:\n└─ \u0026lt;working-directory\u0026gt; ├─ steglitz.osm └─ steglitz.rou.xml  Creating the database\nWe\u0026rsquo;ll start off by solely creating the database and applying OSMOSIS with the following command:\njava -jar scenario-convert.jar --osm2db -i steglitz.osm  The directory should look like this:\n└─ \u0026lt;working-directory\u0026gt; ├─ steglitz.db ├─ steglitz.osm ├─ steglitz.rou.xml └─ steglitz_cleaned.osm  Importing the route-file\nLet\u0026rsquo;s import our routes into the database.\nWe achieve this by calling:\njava -jar scenario-convert.jar --sumo2db -i steglitz.rou.xml -d .\\steglitz.db  Now all new routes are imported into our database. The following image shows a visualization of one of the created routes.\n Visualization of one of the routes   Creating the scenario\nThe final step is to create the scenario from the files we created so far.\njava -jar scenario-convert.jar --db2mosaic -d .\\steglitz.db  Instead of copying our SUMO-files this will generate all necessary files and move them into a Eclipse MOSAIC-conform folder structure:\n└─ \u0026lt;working-directory\u0026gt; ├─ steglitz.osm └─ steglitz ├─ application | └─ steglitz.db ├─ mapping | └─ mapping_config.json ├─ sumo | ├─ steglitz.net.xml | └─ steglitz.sumocfg └─ scenario_config.json  As you can see the resulting folder structure looks just like the final output from the first workflow described.\nConclusion\nYou should now know how you can manually add routes to your scenario and have a deeper understanding of the way that some of the script parameters work.\nAttached Files A list of all attached files in this chapter:\n  Steglitz OSM-file    Steglitz Route-file    Reference documentation for scenario-convert Usage of scenario-convert The following listing shows an overview for the usage of scenario-convert:\nusage: scenario-convert [OPERATION] [OPTIONS] Examples: 1. Import an osm file and write data into database \u0026gt; scenario-convert --osm2db -i \u0026lt;OSMFILE\u0026gt; [-d \u0026lt;DATABASE\u0026gt;] 2. Export database content to SUMO-readable files \u0026gt; scenario-convert --db2sumo -d \u0026lt;DATABASE\u0026gt; [-s \u0026lt;SUMOPREFIX\u0026gt;] 3. Import a SUMO routefile into a database \u0026gt; scenario-convert --sumo2db -d \u0026lt;DATABASE\u0026gt; -i \u0026lt;ROUTEFILE\u0026gt;.rou.xml 4. Combine steps 1 and 2 \u0026gt; scenario-convert --osm2sumo -d \u0026lt;DATABASE\u0026gt; -i \u0026lt;OSMFILE\u0026gt; [-s \u0026lt;SUMOPREFIX\u0026gt;] 5. Export db content to Shapefile format \u0026gt; scenario-convert --db2shp -d \u0026lt;DATABASE\u0026gt; 6. Import an srtm file and write elevation data to nodes of an existing database \u0026gt; scenario-convert --srtm2db -i \u0026lt;SRTMFILE\u0026gt; -d \u0026lt;DATABASE\u0026gt; 7. Create a complete MOSAIC scenario from an osm file \u0026gt; scenario-convert --osm2mosaic -i \u0026lt;OSMFILE\u0026gt; 8. Create a scenario database from an SUMO net file \u0026gt; scenario-convert --sumo2db -i \u0026lt;NETFILE\u0026gt;.net.xml 9. Calculate a route from node 123 to node 456 \u0026gt; scenario-convert --generate-routes -d \u0026lt;DATABASE\u0026gt; --route-begin-node-id 123 --route-end-node-id 456 The following arguments are available: -h,--help Prints this help screen. -c,--config-file \u0026lt;PATH\u0026gt; Optional, refers to a configuration file which contains all parameters in JSON format. --osm2db Converts a OpenStreetMap file to a new scenario database. --sumo2db Imports a SUMO Network/Routefile. Be aware that you may have to re-export an imported network. --srtm2db Imports an SRTM file and writes elevation data to nodes. --db2sumo Exports the network to SUMO node and edge files. --db2shp Exports the database into Shapefile format. --db2mosaic Creates directory structure for a MOSAIC scenario based on the database contents. --osm2sumo Combination of osm2db and db2sumo. --osm2mosaic Combination of osm2db and db2mosaic. --update Updates the database to the current scheme. -d,--database \u0026lt;PATH\u0026gt; The path to the database. For import: File to import to. If not given, a new file is created. For export: File to load from. For update operations: file to update. -i,--input \u0026lt;PATH\u0026gt; Defines an input file to use in an import. File type depends on the import operation (OSM File/Database file/SUMO net file/SUMO rou file). -s,--sumo-prefix \u0026lt;STRING\u0026gt; Prefix for the generated sumo files (uses database name when not defined). -f,--force Force overwrite of existing files instead of incrementing file names. -m,--mapping-file \u0026lt;PATH\u0026gt; Uses the given mapping configuration to export existing vehicleTypes and vehicles data to *.rou.xml. --import-lat \u0026lt;DOUBLE\u0026gt; Center latitude of imported region to project coordinates. --import-lon \u0026lt;DOUBLE\u0026gt; Center longitude of imported region to project coordinates. --import-zone \u0026lt;STRING\u0026gt; UTM zone of location for projecting coords in default format (e.g. 32n). -g,--generate-routes Generates route(s) from one point to another. The begin and end for the route must be known (see below options). --route-begin-lat \u0026lt;DOUBLE\u0026gt; Latitude of the starting point, needs --route-begin-lon as well. --route-begin-lon \u0026lt;DOUBLE\u0026gt; Longitude of the starting point, needs --route-begin-lat as well. --route-begin-latlon \u0026lt;DOUBLE,DOUBLE\u0026gt; [latitude],[longitude] of the starting point. --route-begin-node-id \u0026lt;STRING\u0026gt; OSM node id of the starting point (use instead of lat/lon). --route-end-lat \u0026lt;DOUBLE\u0026gt; Latitude of the starting point, needs --route-end-lon as well. --route-end-lon \u0026lt;DOUBLE\u0026gt; Longitude of the starting point, needs --route-end-lat as well. --route-end-latlon \u0026lt;DOUBLE,DOUBLE\u0026gt; [latitude],[longitude] of the ending point. --route-end-node-id \u0026lt;STRING\u0026gt; OSM node id of the ending point (use instead of lat/lon). --route-matrix \u0026lt;STRING,STRING,...\u0026gt; Calculates all possible routes starting and ending at the given nodes, given as comma-separated list (e.g. 12345,87123,89123) --number-of-routes \u0026lt;INTEGER\u0026gt; Defines the number of alternative routes to be calculated (default=1). --skip-osm-filter Skips automatic filtering of the OSM file (only with osm2xxx). --skip-turn-restrictions Ignore all defined turn restrictions on OSM import. --skip-graph-cleanup Turns off the removal of unconnected parts from the main traffic network graph . Since several components of VSimRTI require one main graph without disconnected ways and nodes, this option should be used only if the cleanup procedure is faulty. --skip-netconvert Skips starting sumo netconvert for creating netfile (only with xxx2sumo). --skip-traffic-lights-export Skips exporting traffic light information for nodes (only with xxx2sumo). --osm-speeds-file \u0026lt;PATH\u0026gt; Define a property file which contains speed information which are used to set the speed for OSM ways without a max speed tag (only with osm2xxx). --osm-speeds-overwrite If set to true , the maxspeed tags of ways are ignored and replaced by either default values , or by speed information defined via the --osm-speeds-file option (only with osm2xxx).  Configuration-files for scenario-convert Scenario-convert offers a way to safe your conversion-parameters in a JSON configuration file using the option -c or --config-file.\nThe following listing shows how to save the options used in the example above:\n{ \u0026#34;operatingMode\u0026#34;: \u0026#34;osm2mosaic\u0026#34;, \u0026#34;inputFile\u0026#34;: \u0026#34;steglitz.osm\u0026#34;, \u0026#34;executeOsmosis\u0026#34;: true, \u0026#34;generateRoutes\u0026#34;: true, \u0026#34;routeBeginLatLon\u0026#34;: \u0026#34;52.457616,13.318392\u0026#34;, \u0026#34;routeEndLatLon\u0026#34;: \u0026#34;52.454774,13.333554\u0026#34;, \u0026#34;numberOfRoutes\u0026#34;: 3 }  Speed-files Below you can find a properties file which can be used during the import of OSM data in order to define speeds for ways, which do not have a maxspeeds-tag defined. For this purpose use the option --osm-speeds-file \u0026lt;FILE\u0026gt;. In the speed properties file, for each way type a speed value can be defined, according to the OSM highway  key.\n# the unit the speed values are defined in [kmh, ms] speed.unit = kmh # the default speed for all way types which are not defined here speed.default = 30 # autobahn highway.motorway = 130 highway.motorway_link = 70 # bundesstrasse (germany) highway.trunk = 70 highway.trunk_link = 65 # linking bigger town highway.primary = 65 highway.primary_link = 60 # linking towns \u0026#43; villages highway.secondary = 60 highway.secondary_link = 50 #streets without middle line separation highway.tertiary = 50 highway.tertiary_link = 40 highway.residential = 30 #special roads highway.living_street = 5 highway.service = 20 # unclassified roads highway.unclassified = 30 highway.road = 20 # forest tracks highway.track 15  ","date":1557010800,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1557010800,"objectID":"485ead0ca3596dfe810e10c66ea5a027","permalink":"https://www.eclipse.org/mosaic/docs/building_scenarios/scenario_convert/","publishdate":"2019-05-05T00:00:00+01:00","relpermalink":"/mosaic/docs/building_scenarios/scenario_convert/","section":"docs","summary":"The tool scenario-convert is part of MOSAIC Extended.\nHowever, you can use scenario-convert for free to generate scenarios which are executable with Eclipse MOSAIC. Get it here.\n  Download scenario-convert from DCAITI mirror  scenario-convert is a useful tool, which can be used to create new scenarios or import and export data from external sources like OpenStreetMap, SUMO etc into your existing scenarios.","tags":null,"title":"Scenario Convert","type":"docs"},{"authors":null,"categories":null,"content":"Eclipse MOSAIC generates log files for each simulation run. Log files are generated for the ambassadors of each coupled federate respectively simulator and for the RTI itself. The log files are stored in the folder \u0026lt;mosaic-root\u0026gt;/logs/log-\u0026lt;timestamp\u0026gt;. For each simulation run a new folder is created.\n└─ log-\u0026lt;timestamp\u0026gt; ├─ apps | └─ \u0026lt;unitType\u0026gt;_\u0026lt;unitId\u0026gt; ................. Detailed application specific logs for each unit | ├─ OperatingSystem.log ............. Detailed operating system logs for the unit | └─ ExampleApp.log .................. Detailed application specific logs for each application. ├─ activities.csv ......................... Simulation details in comma separated value-format ├─ Application.log ....................... Information about the application ambassador ├─ Cell.log ............................... Cellular network log ├─ ChargingStation.log .................... ChargingStation ambassador log ├─ Communication.log ...................... (Ad hoc) network simulation ambassador log ├─ CommunicationDetails.log ............... Detailed output of network simulator (ns-3 or OMNeT++) ├─ Environment.log ........................ Logs of the environmental eventserver ├─ Mapping.log ............................ Mapping configuration logs ├─ MOSAIC.log ............................. General information, e.g. startup sequence information ├─ Navigation.log ......................... Detailed logs about navigation component in the application ambassador ├─ Traffic.log ............................ Traffic simulation log (SUMO or others) └─ output.csv ............................. Recorded data of the integrated File Output Generator  In addition to standard logging output for each federate there is a activities.csv file which contains detailed information about sent and received interactions. This file can be used to trace a simulation run for deep debugging. To enable this feature, the log level of the logger activities has to be set to INFO in the logback.xml (see section below).\nLogging The main configuration file for logging is \u0026lt;mosaic-root\u0026gt;/etc/logback.xml. In this file, the log output can be configured in great detail. This file can be adjusted to your needs, e.g. you can set up a more detailed logging for communication components but set a less verbose output for Eclipse MOSAIC\u0026rsquo;s internal interactions or traffic simulation depending on your simulation focus.\nEclipse MOSAIC uses LOGback as logging framework. LOGback offers a lot of parameters to adapt the output to your needs. Please refer to this site  for a detailed overview of all parameters you can use in the logback.xml file.\nPlease note that you can adjust the output to your needs by setting different log levels (ERROR, INFO, DEBUG etc.) for each component in the file at \u0026lt;mosaic-root\u0026gt;/etc/logback.xml. This might also influence the simulation performance because of a possibly high amount of data to be logged.\nFederate specific logging Depending on the simulation purpose, further configuration possibilities for federate specific logging may be of interest.\nFor instance, OMNeT++ exhibits an elaborated logging concept. The omnetpp.ini in the scenario folder includes options to adjust the logging levels. The outputs of this federate are written to CommunicationDetails.log.\n","date":1557010800,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1557010800,"objectID":"04c4360361ca431828fb0a3f8cfd6c16","permalink":"https://www.eclipse.org/mosaic/docs/getting_started/results/","publishdate":"2019-05-05T00:00:00+01:00","relpermalink":"/mosaic/docs/getting_started/results/","section":"docs","summary":"Eclipse MOSAIC generates log files for each simulation run. Log files are generated for the ambassadors of each coupled federate respectively simulator and for the RTI itself. The log files are stored in the folder \u0026lt;mosaic-root\u0026gt;/logs/log-\u0026lt;timestamp\u0026gt;.","tags":null,"title":"Simulation Results","type":"docs"},{"authors":null,"categories":null,"content":"This section provides general information which helps to couple your own simulator with Eclipse MOSAIC. For a successful coupling, two parts are required: the Federate Ambassador is the communication interface between the RTI and your simulator. It implements predefined interfaces of the Eclipse MOSAIC core library and is directly coupled with Eclipse MOSAIC. Second, your simulator needs to communicate with the Federate Ambassador. For this purpose, you either need to implement your own protocol to control the simulator, or use existing ones of your respective simulator (e.g. SUMO provides the TraCI byte buffer protocol).\n Implementing a Federate Ambassador In order to simplify federate development and to make the usage of the mechanisms provided by the RTI safer, an abstract class called AbstractFederateAmbassador is provided by the Eclipse MOSAIC core package. It implements the FederateAmbassador interface and handles incoming interactions as well as time advance grants according to the specified federate behaviour. When a federate implementation is making use of the AbstractFederateAmbassador as a super class, it has to provide two information to the superclass while constructing an instance of the class. These are:\n  isTimeConstrained: The general way this parameter can be understood, is that if it is set to true the federate is sensitive towards the time stamp order of interactions. The AbstractFederateAmbassador will then queue incoming interactions and request a time advance from the RTI in order to ensure that processing the received interaction is safe. At the time the requested time advance is granted, every queued interaction with a time stamp smaller or equal to the granted time will be delivered to the federate for processing. If set to false, incoming interactions will be forwarded immediately to the federate, thus resulting in a receive-order of interactions at the federate.\n  isTimeRegulating: Specifies whether the federate will publish time stamped interactions and thus can influence the time advances of other federates in the federation. If set to true, the AbstractFederateAmbassador will request time advances with respect to the specified lookahead value of the federate in order to avoid that time management schedules the execution of other federates while queued interactions are processed. If set to false, time advance requests that are issued due to incoming interactions will be flagged with an unlimited lookahead, allowing the RTI to schedule other federates while incoming interactions are processed.\n   Flowchart of Interaction handling   Further notes Coupling a multitude of different simulators and properly syncing them is a non-trivial task and requires a lot of effort in order to function correctly. If you have read up on High Level Architecture before (have a look here  and at the linked references) you might notice, that the previous flowchart does not completely reflect the proposed mechanisms. For instance, the isTimeRegulating flag has no effect, when the isTimeConstrained flag is not set.\nSo at some points you might stumble upon federates, which have their isTimeConstrained and isTimeRegulating flags set to different values as you would expect. An example of this is the ApplicationAmbassador. One would expect it to be time-constrained as well as time-regulating. This isn\u0026rsquo;t the case though, because the ApplicationAmbassador implements its own time- and event-management, which would interfere with the internal mechanisms.\nWhen implementing your own federate, you can use the existing ones as reference.\nExample A federate that is timeConstrained and timeRegulated can handle a time stamped interaction only after receiving a corresponding time advance grant. For that reason, the AbstractFederateAmbassador caches the incoming interactions in a local queue and requests a time advance with the interactions time stamp. After getting a grant for that time stamp, it forwards the interaction via the processInteraction method call and afterwards invokes processTimeAdvanceGrant to allow the federate to proceed in its local simulation time. In the activity diagram in the following figure, the process of handling of incoming interactions with respect to the federate configuration is illustrated.\n Sequence diagram illustrating the flow of information.   Integration into Eclipse MOSAIC The first step to integrate a new component is the extension of the configuration file etc/runtime.json. An example for a federate configuration can be found in following listing.\n\u0026quot;federates\u0026quot;: [ ... { \u0026quot;id\u0026quot;: \u0026quot;omnetpp\u0026quot;, \u0026quot;classname\u0026quot;: \u0026quot;org.eclipse.mosaic.fed.omnetpp.ambassador.OmnetppAmbassador\u0026quot;, \u0026quot;configuration\u0026quot;: \u0026quot;omnetpp_config.json\u0026quot;, \u0026quot;configurationDeployPath\u0026quot;: \u0026quot;omnetpp-federate/simulations\u0026quot;, \u0026quot;priority\u0026quot;: 50, \u0026quot;dockerImage\u0026quot;: \u0026quot;\u0026quot;, \u0026quot;host\u0026quot;: \u0026quot;local\u0026quot;, \u0026quot;port\u0026quot;: 4998, \u0026quot;deploy\u0026quot;: true, \u0026quot;start\u0026quot;: true, \u0026quot;subscriptions\u0026quot;: [ \u0026quot;VehicleRegistration\u0026quot;, \u0026quot;RsuRegistration\u0026quot;, \u0026quot;TrafficLightRegistration\u0026quot;, ... ], \u0026quot;javaClasspathEntries\u0026quot;: [] }, ... ]  The following parameters are available:\n  class - Attribute giving the full qualified name of the Java class which implements the Feder- ateAmbassador interface.\n  id - The id of the federate. This value should be as short as possible and will be also used for identifying the configuration folder within scenarios.\n  deploy - If set to true, the federate placed under bin/fed/ will be copied to the execution host (according to the host configuration file).\n  start - If set to true, the federate will be started by the federation management using the start command specified in the configuration file or this implementation.\n  subscriptions - A list of interaction names which the Federate Ambassador subscribes for. If any other ambassador sends out one of those interactions, this ambassador will receive them.\n   Interaction extension Another possibility to extend Eclipse MOSAIC is to add a new interaction to the set of predefined interactions. In the following figure, the abstract class Interaction, implemented interaction extensions, and a place holder for further extensions (rectangles with grey fonts and a dotted border) are illustrated. When the InteractionManagement forwards interactions among federates, it chooses the destination based on a interaction id and an optional condition. Furthermore, it synchronizes the interaction delivery based on their times. The abstract class Interaction offers these attributes but no further content. The exchanged content has to be implemented by extending the class Interaction. The already implemented extensions cover the content necessary to simulate common scenarios. However, for further scenarios further interactions might be required.\n Interaction classes and their relationships..   ","date":1557010800,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1557010800,"objectID":"029b4f7b54e0aba61d23421e910663b7","permalink":"https://www.eclipse.org/mosaic/docs/extending_mosaic/simulator_coupling/","publishdate":"2019-05-05T00:00:00+01:00","relpermalink":"/mosaic/docs/extending_mosaic/simulator_coupling/","section":"docs","summary":"This section provides general information which helps to couple your own simulator with Eclipse MOSAIC. For a successful coupling, two parts are required: the Federate Ambassador is the communication interface between the RTI and your simulator.","tags":null,"title":"Simulator Coupling","type":"docs"},{"authors":null,"categories":null,"content":"","date":-62135596800,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":-62135596800,"objectID":"5a65785fcf26ff856f02501a2dff644b","permalink":"https://www.eclipse.org/mosaic/group/dcaiti/","publishdate":"0001-01-01T00:00:00Z","relpermalink":"/mosaic/group/dcaiti/","section":"group","summary":"The **Daimler Center for Automotive IT Innovations (DCAITI)** was founded in 2006 as a joint initiative of Daimler AG and the Technical University of Berlin. The DCAITI uses Eclipse MOSAIC since many years for various research projects in the field of automated and connected driving. Together with the TU Berlin students gain practical experience in software development by using and extending this simulation framework and models.","tags":null,"title":"","type":"group"},{"authors":null,"categories":null,"content":"Eclipse SUMO is an highly portable, microscopic and continuous road traffic simulation tool. It is designed to handle large road networks faster than real-time and simulates each vehicle individually.\n          Operating System GNU/Linux and Microsoft Windows    License EPL-2.0    Website  https://www.eclipse.org/sumo/      Supported versions Recommended version:\nFull support:\nLimited support: 1.8.0\n1.2.0 - 1.8.0\n1.0.1, 1.1.0         Installation Download Eclipse SUMO Download the SUMO binary bundle or installer from the SUMO website. Linux users may build SUMO from the source code. Please refer to the SUMO Wiki for further information.\n In order to run SUMO with Eclipse MOSAIC you need to make the SUMO binaries available system wide by adding the SUMO binary folder to your PATH environment variable. Alternatively, the environment variable SUMO_HOME can be used to define the installation directory of SUMO.\n   We recommend using the 64 bit version of SUMO if you want to simulate scenarios with a big traffic network.\n  Configuration This ambassador can be configured with a configuration file. The specific path is \u0026lt;scenarioName\u0026gt;/sumo/sumo_config.json. If no such file exists, the following default configuration options are used:\n{ \u0026quot;updateInterval\u0026quot;: 1000, \u0026quot;sumoConfigurationFile\u0026quot;: \u0026quot;\u0026lt;scenarioName\u0026gt;.sumo.cfg\u0026quot;, \u0026quot;exitOnInsertionError\u0026quot;: true, \u0026quot;additionalSumoParameters\u0026quot;: \u0026quot;--time-to-teleport 0 --seed 100000\u0026quot;, \u0026quot;subscriptions\u0026quot;: [ \u0026quot;roadposition\u0026quot;, \u0026quot;signals\u0026quot;, \u0026quot;emissions\u0026quot; ], \u0026quot;subscribeToAllVehicles\u0026quot;: true }   Read the detailed documentation of the SUMO Configuration.\n  Next to sumo_config.json, the following configuration files are required for every SUMO simulation scenario:\n└─ \u0026lt;scenario_name\u0026gt; └─ sumo ├─ \u0026lt;scenarioName\u0026gt;.net.xml .............. SUMO Network file ├─ \u0026lt;scenarioName\u0026gt;.rou.xml .............. SUMO Route file ├─ \u0026lt;scenarioName\u0026gt;.sumocfg .............. SUMO configuration file └─ sumo_config.json .................... Ambassador configuraition file]  The SUMO configuration consists of sumo specific config files and the sumo-ambassador configuration file. The main configuration file name must end with the suffix *.cfg, which needs to refer to the network and route files. The network file is mandatory and should be generated with the scenario-convert tool provided with Eclipse MOSAIC.\nThe \u0026lt;scenarioName\u0026gt;.rou.xml is optional and is generated automatically for each simulation run. The routes for each vehicle are then usualy taken from the scenario database. However, those routes can be overriden by defining them manually in the route file.\n Eclipse MOSAIC ignores SUMOs *.rou.xml files\nWith Eclipse MOSAIC, the traffic definition (definition of vehicles, flows, vehicle types) is part of the Mapping configuration file. Any vehicles or flows defined within the \u0026lt;scenarioName\u0026gt;.rou.xml are ignored and won’t be simulated by SUMO.\n  Vehicle related parameters, such as acceleration, maximum speed, and the like, are configured via the Mapping configuration file. However, some SUMO specific parameters, like the car following model, needs to be configured separately in the route file. For example, if you have configured a vehicle type called MyVehicle in the Mapping configuration, you can set specific parameters for this type in the \u0026lt;scenarioName\u0026gt;.rou.xml as following:\n\u0026lt;routes\u0026gt; \u0026lt;vType id=\u0026quot;MyVehicle\u0026quot; carFollowModel=\u0026quot;IDM\u0026quot; lcKeepRight=\u0026quot;10\u0026quot;\u0026gt; \u0026lt;/routes\u0026gt;  Further information about SUMO and its configuration can be found in the official SUMO wiki.\nUsing the SUMO GUI with Eclipse MOSAIC It is also possible to use the graphical interface of SUMO in order to visualize and interact with the simulation. To achieve this, Eclipse MOSAIC can be configured to start the GUI process of SUMO as the federate rather than the command line interface. In order to use the SUMO GUI the file \u0026lt;mosaic\u0026gt;/etc/runtime.json needs to be edited. Here, the entry org.eclipse.mosaic.fed.sumo.ambassador.SumoAmbassador must be replaced with org.eclipse.mosaic.fed.sumo.ambassador.SumoGuiAmbassador.\n Keep in mind to launch Eclipse MOSAIC with the argument -w 0 in order to disable the watchdog timer. Otherwise, it would shut down Eclipse MOSAIC if the simulation is paused in the SUMO GUI.\n  ","date":-62135596800,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":-62135596800,"objectID":"86514c669b0224d14af4801daf24dc4c","permalink":"https://www.eclipse.org/mosaic/docs/simulators/traffic_simulator_sumo/","publishdate":"0001-01-01T00:00:00Z","relpermalink":"/mosaic/docs/simulators/traffic_simulator_sumo/","section":"docs","summary":"Eclipse SUMO is an highly portable, microscopic and continuous road traffic simulation tool. It is designed to handle large road networks faster than real-time and simulates each vehicle individually.\n          Operating System GNU/Linux and Microsoft Windows    License EPL-2.","tags":null,"title":"Eclipse SUMO - Simulation of Urban MObility","type":"docs"},{"authors":null,"categories":null,"content":"This chapter is intended to document interactions that can be sent and received between Eclipse MOSAIC federates in order to enable users to easily design and integrate new federates and connect them to existing federates. Note that we use the word \u0026ldquo;interaction\u0026rdquo; whenever we describe communication between federates, whereas we talk about a \u0026ldquo;message\u0026rdquo; primarily when concerned with V2X-communication.\nAll interactions are categorized by the package they are contained in, which corresponds to their main context/purpose. The \u0026ldquo;Sent by\u0026rdquo; column is not necessarily complete for all interactions but should give an idea where interactions are used.\nmapping All interactions in this package are concerned with adding/registering simulation-units to the simulation. While most of the introductions are handled by the Mapping- or Application-ambassador, some of them are handled by the ambassadors for the traffic simulators (see LuST  -scenario). In this case the interactions are used to initialize the scenario.\n   Interaction name Description Sent by     VehicleRegistration This interaction is sent by the vehicle mapping component to indicate the introduction of a new vehicle to the simulation. Note, this does not necessarily imply that the added vehicle is already simulated by the traffic simulator. Mapping\nApplication   ChargingStationRegistration This interaction indicates the introduction of a charging station to the simulation. All units are introduced at simulation start time, e.g. 0s. Mapping   RsuRegistration This interaction indicates the introduction of a roadside unit to the simulation. Mapping   TmcRegistration This interaction indicates the introduction of a traffic management center to the simulation. It holds a list of all applications and all induction loops and lane are detectors the TMC is responsible for. Mapping   ServerRegistration This interaction indicates the introduction of a server to the simulation. It holds a list of all applications. Mapping3   TrafficLightRegistration This interaction indicates the introduction of a traffic light (group) to the simulation. It holds a traffic light group, which unites all traffic light signals used for one traffic light system. Mapping   TrafficSignRegistration This interaction indicates the introduction of a traffic sign. Mapping    mapping.advanced Interactions in this package are still concerned with the mapping of vehicles but differ from simple simulation unit registration.\n   Interaction name Description Sent by     ScenarioTrafficLightRegistration This interaction contains the phases and their duration of each traffic light in the simulation. This interaction shall be generated by the traffic simulators at start up (e.g. SUMO) Sumo\nPhabmacs   ScenarioVehicleRegistration This interaction is used to add vehicles to a simulation using a preconfigured scenario, which could be defined by using Sumo. Sumo(Scenario)   RoutelessVehicleRegistration This interaction is sent the vehicle mapping component to indicate the introduction of a new vehicle whose route is not yet known. This interaction is usually handled by the Application-ambassador, which calculates a route for the given vehicle and sends out an VehicleRegistration-interaction afterwards. Mapping    communication This package contains interactions regarding the setup of communication-components in simulation units and interactions concerned with the transfer of V2X-messages.\n   Interaction name Description Sent by     AdHocCommunicationConfiguration This interaction is intended to be used to exchange information about the configuration of a vehicle’s ad-hoc communication facilities. Application   CellularCommunicationConfiguration This interaction is intended to be used to exchange information about the configuration of a vehicle’s cellular communication facilities. Application    Interactions related to V2X-message transfer.\n   Interaction name Description Sent by     V2xMessageAcknowledgement This interaction is used by a communication simulator to inform about success or failure of a packet transmission. Typically, the application simulator should subscribe to this interaction. Cell   V2xMessageReception This interaction is intended to be used to exchange information about a received V2X message. Omnet++\nns-3\nSimpleNetworkSimulator\ncell   V2xFullMessageReception This interaction carries the payload that represents an arbitrary V2XMessage that is supposed to be received by the receiver of this Eclipse MOSAIC Interaction. Omnet++\nns-3\nSimpleNetworkSimulator\nCell   V2xMessageRemoval This interaction is intended to be used to exchange information about V2X messages, that are to be deleted. Application   V2xMessageTransmission This interaction is sent in order to trigger the transportation of a V2XMessage over a wireless network to a given geographical destination area. Application    vehicle The interactions contained in this package are usually used to enable applications to forward vehicle-control to the used traffic simulators.\n   Interaction name Description Sent by     VehicleActuatorsChange This interaction is used to directly control the throttle/brake of an vehicle. At the moment this is only supported by Phabmacs. Application   VehicleDistanceSensorActivation This interaction is used to enable the distance sensors of a vehicle. A multitude of sensors can be enabled with one interaction given they use the same maximum lookahead distance. Application   VehicleFederateAssignment This interaction is intended to be used, when more than one traffic simulator is used in a simulation. It enables the passing of information on which vehicle are passed externally. At the moment this is used by the PhSCA-ambassador. PhaSCA   VehicleLaneChange This interaction initiates a lane change for the given vehicle, which should be consumed by the traffic simulators. Application   VehicleParametersChange This interaction requests to update various parameters of the vehicle or its driver. Application   VehicleResume This interaction requests the given vehicle to continue its journey after being stopped beforehand. The interaction should be handled by traffic simulators Application   VehicleRouteChange This interaction is used to change a route for vehicle by its id. It can be assumed that the given route id has been propagated by either a VehicleRoutesInitialization- or VehicleRouteRegistration-interaction. Application   VehicleRouteRegistration This interaction is used to propagate a newly generated route which is not yet known. It consists of the id of the route and a list of all its edges. Application   VehicleSightDistanceConfiguration This interaction is used to configure the sight distance for a vehicle (driver), this information can for example be used to implement applications regarding traffic sign recognition. Application   VehicleSlowDown This interaction initiates the vehicle to slow down in a given interval. The request should be handled by traffic simulators. The name \u0026lsquo;SlowDown\u0026rsquo; is inherited by Sumo and a little bit misleading, the speed can also be increased. Application   VehicleSpeedChange This interaction sets the current speed of the given vehicle. This should be handled by traffic simulators Application   VehicleStop This interaction requests the given vehicle to stop at the given road position, it should be handled by traffic simulators. Application    traffic Interactions in this package are focused around traffic management and communication with traffic simulators.\n   Interaction name Description Sent by     CellularHandoverUpdates This interaction is used by the cell ambassador to communicate handovers. cell   InductionLoopDetectorSubscription This interaction subscribes a unit to the data of an induction loop detector, usually this will be TMCs. In order to retrieve the data, traffic simulators have to be told to omit the subscribed data. Application   LaneAreaDetectorSubscription This interaction subscribes a unit to the data of a lane area detector, usually this will be TMCs. In order to retrieve the data, traffic simulators have to be told to omit the subscribed data. Application   LanePropertyChange This interaction contains lane properties to be changed. Concretely, it sets a list of allowed and disallowed vehicle classes per lane and a new maximum speed limit that shall be changed. The changed lane properties have to be omitted to the traffic simulator to be handled. Application   TrafficDetectorUpdates This extension of {@link Interaction} combines updates of lane area and induction loop detectors. Usually the updates are supplied by the traffic simulator and will be filtered by applications subscribed to them. Sumo   TrafficLightStateChange This interaction is intended to be used to forward a request to change the state of a simulated traffic light. This interaction can be used to implement different controlling strategies for traffic lights. Application   TrafficLightUpdate This interaction is a container for traffic light update. It is sent by the SumoAmbassador to inform simulation units about an updated traffic light state. Sumo   VehicleUpdates This interaction is used to update the position of some or all vehicles of the simulation. It consists of three lists, containing newly added vehicles, vehicles which were updated since the last simulation step, and vehicles which have been removed from the traffic simulation. Sumo\nPhabmacs   VehicleTypesInitialization This interaction is required for each simulation. It contains predefined vehicle types. Other ambassadors may cache this interaction in order to have access on vehicle types, which are later identified by their identifier. Mapping   VehicleRoutesInitialization This interaction is required for each simulation. It contains all routes vehicles will take during the simulation. Other ambassadors may cache this interaction in order to have access on the routes, which are later identified by their identifier. Application    electricity All interactions contained in this package are related to electric vehicles and the surrounding infrastructure.\n   Interaction name Description Sent by     ChargingDenialResponse This interaction is sent out by the charging station ambassador to inform the application simulator (the vehicles) when a charging station is already in use. e.g. a vehicle wants to start charging on an engaged charging station -\u0026gt; ChargingStartDenial. ChargingStation   ChargingStartResponse This interaction is intended to be used to forward a started charging process at a ChargingSpot to the RTI. ChargingStation   ChargingStationUpdates This extension interaction is intended to be used to forward the updated state of a ChargingStation to the RTI. ChargingStation   ChargingStopResponse This interaction is intended to be used to forward a stopped charging process at a charging station to the RTI. ChargingStation   VehicleChargingStartRequest This interaction is intended to be used to forward a request from a vehicle to start charging its battery at a charging station to the RTI. Application   VehicleChargingStopRequest This interaction is intended to be used to forward a request from a vehicle to stop charging its battery at a charging station to the RTI. Application   VehicleElectricityUpdates This interaction is used to inform the applications of simulation units about changed electric information, send out by the battery ambassador. Battery    environment The interactions in this package are used for handling the communication about environment sensors.\n   Interaction name Description Sent by     EnvironmentSensorActivation This interaction is intended to be used to signal interest in sensor information for a specific simulation unit. Application   EnvironmentSensorUpdates This interaction is intended to be used to exchange sensor data. EventServer   GlobalEnvironmentUpdates This extension of interaction contains a list of current environment events and their locations. Those events can than be used to react upon a changing environment. EventServer    trafficsigns Interactions in this package are used to communicate changes in variable traffic signs, e.g. changing the speed limit.\n   Interaction name Description Sent by     AbstractTrafficSignChange This interaction can be sent to traffic sign ambassador in order to change a variable traffic sign. All interaction-classes, that are concerned with changing traffic signs extend this class. Application   TrafficSignLaneAssignmentChange This interaction can be sent to traffic sign ambassador in order to change a variable lane assignment sign. Application   TrafficSignSpeedLimitChange This interaction can be sent to traffic sign ambassador in order to change a variable speed sign. Application   VehicleSeenTrafficSingsUpdate This interaction stores a map of all traffic signs which are in sight distance of a specific vehicle and a map of all traffic signs which became invalid for that vehicle. TrafficSign    application Interactions in this package are used for applications. They are used to communicate custom information/data via the RTI.\n   Interaction name Description Sent by     ApplicationInteraction This interaction is intended to be used in custom applications, it can be extended for simulation units to react upon different influences and can be used for intercommunication between applications. Application   ItefLogging This interaction is used to exchange log-tuples for the ITEF (Integrated Testing and Evaluation Framework). Application   SumoTraciRequest This interaction is used to send a byte array message to SUMO TraCI. The request will be handled by TraCI and trigger a SumoTraciResponse. Application   SumoTraciResponse This interaction holds the TraCI response for a SumoTraciRequest. It is sent by the SumoAmbassador and will usually be handled by the Application that sent the request. Sumo    ","date":1596672000,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1596672000,"objectID":"7f431be72ccf4101c02872c325977e3f","permalink":"https://www.eclipse.org/mosaic/docs/extending_mosaic/interactions/","publishdate":"2020-08-06T00:00:00Z","relpermalink":"/mosaic/docs/extending_mosaic/interactions/","section":"docs","summary":"This chapter is intended to document interactions that can be sent and received between Eclipse MOSAIC federates in order to enable users to easily design and integrate new federates and connect them to existing federates.","tags":null,"title":"Interactions in Eclipse MOSAIC","type":"docs"},{"authors":null,"categories":null,"content":"This chapter aims to give you a brief overview of additional simulators and visualizers that can be used with Eclipse MOSAIC. We will continue with the tutorial-style explanations following up on the Steglitz-example from the previous chapter  . For more detailed explanations of the configurations have a look at this chapter  .\nIf you already played with the Barnim  -tutorial you probably noticed, that it contains far more folders in the scenario structure compared to the Steglitz example. Those additional directories contain configurations for various simulators.\n└─ Barnim ├─ application ├─ cell ├─ environment ├─ mapping ├─ ns3 ├─ output ├─ sns ├─ sumo └─ scenario_config.json .................. Basic configuration of the simulation scenario  Let the cars loose As a starting point we\u0026rsquo;ll look at the scenario that we created using this command:\njava -jar scenario-convert.jar --osm2mosaic -i steglitz.osm -o --generate-routes --route-begin-latlon 52.4551693,13.3193474 --route-end-latlon 52.4643101,13.3206834 --number-of-routes 3  We\u0026rsquo;ll end up with a folder looking like this:\n└─ steglitz ├─ application | └─ steglitz.db ├─ mapping | └─ mapping_config.json ├─ sumo | ├─ steglitz.net.xml | └─ steglitz.sumocfg └─ scenario_config.json .................. Basic configuration of the simulation scenario  If you have a look in the mapping_config.json  , you can see that the scenario-convert script automatically assigns cars to the three routes created. You can use this file as a blueprint for your own scenario, have a look here  to get more details on possible adaptions.\nBelow is a short video of the scenario displayed in the SUMO-GUI. We marked the three different routes the cars follow.\n Communication Simulators (cell, ns3, omnetpp, sns) We won\u0026rsquo;t implement any functionality for the steglitz example here but rather have a look at the Barnim  -tutorial. In the scenario_config.json of the Barnim scenario you can see where the communication simulators are activated:\n\u0026quot;federates\u0026quot;: { \u0026quot;cell\u0026quot;: false, \u0026quot;omnetpp\u0026quot;: false, \u0026quot;ns3\u0026quot;: false, \u0026quot;sns\u0026quot;: true }  Our tutorials  and additional examples  demonstrate use cases for communication usages and you should have a look at them if you are uncertain where to start. Furthermore we recommend copying the configuration-files for the simulator you are going to use from the Barnim scenario  . It contains the most complete configurations and is well maintained.\nIf you are an expert with one of the external network simulators ( ns3  , OMNeT++  ) the Barnim scenario will also give you an overview on how to configure those.\nOther Simulators Here we\u0026rsquo;ll discuss two simulators integrated with Eclipse MOSAIC and their use-cases, namely the Event Server and the Battery Simulator.\nEvent server The event server can be used to emit events to vehicles inside it\u0026rsquo;s predefined borders. In the Barnim scenario an event server is used to simulate an icy area, which is then noticed by the sensor of a weather server RSU.\nEvery defined event requires a type, a defined geographical area (e.g. circular, rectangular), the strength and a time frame. Have a look at the eventserver_config.json  to see how this can be configured. If you want to use the event server make sure to have it enabled in the scenario_config.json.\nBattery The battery simulator is used to simulate electric vehicles. It offers a lot of customization, because you can dynamically load your own battery, vehicle and environment models. Have a look a the battery_config.json  , taken from the Barnim scenario. The three models used are included with Eclipse MOSAIC and you can freely use them.\nOutput There are various options to generate output results of your simulations (see the visualization chapter  ).\nThe first step is to create a file called output_config.xml in a new directory called output. If you used the scenario-convert tool the file should be generated automatically.\n└─ steglitz ├─ application | └─ steglitz.db ├─ mapping | └─ mapping_config.json ├─ output | └─ output_config.xml ├─ sumo | ├─ steglitz.net.xml | └─ steglitz.sumocfg └─ scenario_config.json .................. Basic configuration of the simulation scenario  Example configuration for output generation can be taken from the example scenarios from the tutorials section.\nNext make sure the visualization federate is activated in the scenario_config.json.\n``` Now we have to configure the statistics visualizer itself. This [visualizer_config.xml](/docs/building_scenarios/files/steglitz_visualizer_config.xml) contains the basic configuration in order to calculate the average travel times for the vehicles. If you want to make adaptions, please refer to [statistics visualizer](/docs/visualization/statistics). Go ahead and run the simulation one more time. Afterwards the log-directory should contain a file called `AverageVehicleTravelTime.csv` in a directory called `StatisticsVisualizer`: ```csv group;group-value;total; Car;186.369;336; ``` This tells us that there was a total amount of 336 vehicles of the type `Car` in the simulation, which traveled for 186.369 seconds on average. -- Conclusion\nAfter this small, hands-on introduction to visualizers you should know where to configure them and after some additional reading, you should be able to configure different types of visualizers for your use-cases.\n","date":1557010800,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1557010800,"objectID":"a4ca6c187ad91d08aae3125ab16bd8e7","permalink":"https://www.eclipse.org/mosaic/docs/building_scenarios/scenario_configuration/","publishdate":"2019-05-05T00:00:00+01:00","relpermalink":"/mosaic/docs/building_scenarios/scenario_configuration/","section":"docs","summary":"This chapter aims to give you a brief overview of additional simulators and visualizers that can be used with Eclipse MOSAIC. We will continue with the tutorial-style explanations following up on the Steglitz-example from the previous chapter  .","tags":null,"title":"Additional Scenario Configuration","type":"docs"},{"authors":null,"categories":null,"content":"  The Statistics Output Generator is part of MOSAIC Extended.\nFor further information on licenses, feel free to contact us via mosaic@fokus.fraunhofer.de.\n  Statistics Output is another output generating tool to easily measure basic simulation outcomes. You will be able to obtain short or detailed results of the simulation, e.g. travel times or the average speeds of groups of vehicles, or the average flow on induction loops.\nConfiguration  The main configuration file for all output generators is located at \u0026lt;scenarioName\u0026gt;/output/output_config.xml  In order to use the Statistics Output, the attribute enabled of the root element output must be set to \u0026ldquo;true\u0026rdquo;, as shown in the following listing.\n\u0026lt;output id=\u0026quot;statistics\u0026quot; enabled=\u0026quot;true\u0026quot; loader=\u0026quot;com.dcaiti.mosaic.fed.visualizer.StatisticsVisualizerConfig\u0026quot;\u0026gt; [..] \u0026lt;/output\u0026gt;  Configuration header for Statistics Output\nSpecification In this section, we take a closer look at the Statistics Output by using examples and demonstrations. For each type of retrieving data we create a \u0026lt;statistic\u0026gt;\u0026lt;/statistic\u0026gt; block. Inside the block we define one certain data type we want to retrieve in a  element. If you want to retrieve different data types, just create another \u0026lt;statistic\u0026gt; block for each of them.\nYou can also set the wanted file name in the attribute filename of the statistic element. If the attribute has not been given, each \u0026lt;statistic\u0026gt; block will get the name accordingly to the order number, for example 1. StatisticsVisualizer-Block.csv.\nIn the output attribute two options (short|verbose) can be selected. The short option provides us a compact log file with information about only the highest level of the retrieved data (e.g. aggregate values of grouped vehicles) in contrast to verbose option which also provides informations about every individual vehicle in each group.\nFor a successful start, the element source must be placed in the first position in the statistic children element list. Different options of possible data types, one of which must be specified in the source element can be seen below.\n\u0026lt;statistic filename=\u0026quot;ChooseItYourself\u0026quot; output=\u0026quot;short\u0026quot;\u0026gt; \u0026lt;source\u0026gt;NameOfSource\u0026lt;/source\u0026gt; \u0026lt;/statistic\u0026gt;  Source options of Statistics Output\nApplication This section will demonstrate the basic idea and usage of the Statistics Output depending on the individual requirements. Next to retrieving raw data, the Statistics Output has further features for processing of the obtained data.\n source: Data to obtain, choose between:  VehicleSpeeds - Obtain the speeds of the vehicles of each simulation step. VehicleStops - The total number of stops during the journey of each vehicle. VehicleTravelTimes - The total travel time in s of the vehicles. VehicleDelayTimes - The deviation of the travel time compared to the fastest travel time possible for the vehicles (in s). VehicleTravelledDistances - The travelled distance of the vehicles in m. VehicleFuelConsumptions - The fuel consumptions of the vehicles in l per km. VehicleHeadways - Obtain the headway towards the leading vehicle of each vehicle for each simulation step. To obtain this value, an application has to be deployed on the vehicles which activates the front distance sensor. DetectorFlow - The flows of each subscribed induction loop.     For using the detector flow type, inductions loops need to be configured in the SUMO and mapping configuration files (e.g. Highway tutorial).\n   group-by: The vehicles will be grouped by its vehicle type name (VehicleType), group they belong to (VehicleGroup), or obtained data value (e.g. Interval:200 categorizes values into groups of size 200).\n  aggregation: Average | Harmonic aggregation of the obtained values. An attribute deviation can be set to true or false (it’s false if the attribute is not given). This attribute can be used for grouped values to get the deviation of each value from the aggregated group value or to get a standard deviation based on biased sample variance for groups (in the short output version).\n  filter: Filtering with the attribute filterType (possible values are keep and remove).\n Filtering by required value slots with two options to specify them: MoreThan:Value or LessThan:Value (e.g. MoreThan:5 to collect values which are bigger than 5 only) Filtering by vehicle type. VehicleType:Type (e.g. VehicleType:Car to collect values only of vehicles of type \u0026ldquo;Car\u0026rdquo;) Filtering by time. Time:From-To (e.g. Time:0-100 to collect values only of the first 100s of simulation time)    The following example will show an example of how you can specify the Statictics Output according to your desired criteria. VehicleTravelTimes are the data we want to retrieve from vehicles and we want to group vehicles by the abstract group we can define in mapping configuration file (see e.g. Barnim scenario) and then calculate the average vehicle travel time value for each of these groups.\n\u0026lt;output id=\u0026quot;statistics\u0026quot; enabled=\u0026quot;true\u0026quot; loader=\u0026quot;com.dcaiti.mosaic.fed.visualizer.StatisticsVisualizerConfig\u0026quot;\u0026gt; \u0026lt;statistic filename=\u0026quot;AverageVehicleTravelTimes\u0026quot; output=\u0026quot;short\u0026quot;\u0026gt; \u0026lt;source\u0026gt;VehicleTravelTimes\u0026lt;/source\u0026gt; \u0026lt;group-by\u0026gt;VehicleGroup\u0026lt;/group-by\u0026gt; \u0026lt;aggregation\u0026gt;Average\u0026lt;/aggregation\u0026gt; \u0026lt;/statistic\u0026gt; \u0026lt;/output\u0026gt;  Getting the Average time by vehicle class\nYou can also combine filters if you want to get a certain interval with upper and lower boundaries. With the following input instruction, only vehicles with the obtained data values between 250 and 500 will be left after filtering.\n\u0026lt;filter filterType=\u0026quot;keep\u0026quot;\u0026gt;LessThan:500\u0026lt;/filter\u0026gt; \u0026lt;filter filterType=\u0026quot;remove\u0026quot;\u0026gt;LessThan:250\u0026lt;/filter\u0026gt;  An example for filtering\nPlease notice that some sources are being not only obtained in each simulation step but also collected for further processing as separate values for each of these steps (like VehicleSpeeds, VehicleHeadways). These data types need to be aggregated to one value per vehicle if you want to group them by value or filter them.\nFor demonstration, the Statistics Output is configured for the scenario Barnim and calculates the average travel times of the vehicles and additionally groups them. As a result, the simulation produces the following CSV file in the log directory:\nGroup;Value;Total; AdHoc;399.14;24; Cellular;463.87;12; Unequipped;459.18;84;  The AverageVehicleTravelTime.csv file produced by the Statistics Output in the Barnim scenario\n","date":1557010800,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1557010800,"objectID":"f3aea6e70248def0891ed9bd89706cbb","permalink":"https://www.eclipse.org/mosaic/docs/visualization/statistics/","publishdate":"2019-05-05T00:00:00+01:00","relpermalink":"/mosaic/docs/visualization/statistics/","section":"docs","summary":"The Statistics Output Generator is part of MOSAIC Extended.\nFor further information on licenses, feel free to contact us via mosaic@fokus.fraunhofer.de.\n  Statistics Output is another output generating tool to easily measure basic simulation outcomes.","tags":null,"title":"Statistics Output","type":"docs"},{"authors":null,"categories":null,"content":"","date":-62135596800,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":-62135596800,"objectID":"00c72d014237189758fbbed269e91b7d","permalink":"https://www.eclipse.org/mosaic/group/openmobility/","publishdate":"0001-01-01T00:00:00Z","relpermalink":"/mosaic/group/openmobility/","section":"group","summary":"The **openMobility Working Group** was founded to support the development and broad introduction of open source mobility modeling and simulation technologies. The aim of the Working Group is to deliver a openMobility framework of tools based on validated models, which are accepted as standard tools in industry applications and academia. Eclipse MOSAIC is one part of the broad range of tools developed in this group.","tags":null,"title":"","type":"group"},{"authors":null,"categories":null,"content":"The Application Simulator is completely implemented as an Eclipse MOSAIC Ambassador in Java. The main class ApplicationAmbassador is started by the RTI and creates different components, like the SimulationKernel singleton or the CentralNavigationComponent. Subsequently, it will find all the Java Archive (JAR) files in the application configuration directory, belonging to the currently started scenario, and add their classes to the class path. These JARs contain the application classes. Furthermore, the ApplicationAmbassador is registered as a handle for different Eclipse MOSAIC messages in the configuration file etc/runtime.json in the Eclipse MOSAIC folder. After initialization, the Application Simulator will receive these messages from Eclipse MOSAIC when they appear and perform corresponding actions.\nNode Creation  Application Simulator basic flow / node creation classes   Application classes are only instantiated when a node, carrying that application, is created. This is signaled by messages for node creation like (AddedVehicle,AddedRsu,AddedTrafficLight, \u0026hellip;). When the Mapping ambassador spawns a new node, it will send those messages to the RTI. The message then contains the fully qualified names of all applications associated with the spawned node, as well as the vehicle type itself. Depending on this type, the Application Simulator creates a new SimulationUnit object (i.e. a subclass of SimulationUnit like Vehicle, RoadSideUnit or TrafficLight), representing the new node. This task is served by the UnitSimulatorclass, which performs book keeping of all SimulationUnits. Upon Creation of a node, the UnitSimulator will schedule an event to start all applications, belonging to the new node. The required information is saved in a StartApplications object, which also includes a ApplicationUnit object, an abstract representation of a node (a.k.a. unit) having at least one application.\nHowever, as, for example, SUMO does not simulate vehicles strictly from their creation on, but only since their first movement, Applications for vehicles cannot be started directly upon an AddedVehicle message. Instead, every added vehicle will be kept in the addedVehicles Map, until a VehicleMovements message, belonging to that vehicle is processed. The vehicle will then be added by the UnitSimulator like any other node.\nOther Messages and Time Advance Apart from the ones for node creation, there are many other messages (see Interaction  ), signaling events to the Application Simulator. For most of them, an event in the future will be programmed, such that the implied action is carried out at that simulation time. The processing of the events happens when the RTI calls the advanceTime() method on the ambassador. Upon this, Application Simulator will obtain a list of all events up to the new time and let the processor of the event process them. Every potential event processor implements the EventProcessor interface. The corresponding method is the advanceTime() method of ApplicationAmbassador, which calls scheduleEvents() on the event scheduler. Subsequently, some interesting messages and their handling process is sketched shortly:\n   Message Description     VehicleUpdates Signals that a vehicle has moved. The Vehicle object, which is a subclass of SimulationUnit, that corresponds to the moved vehicle will be updated to contain the new position. The new information is encapsulated in a VehicleInfo object, containing different vehicle data. To update the data, an event is scheduled at the given time and processed upon time advance. Vehicles not yet added to the simulation (see Node Creation  ), are added by calling addVehicleIfNotYetAdded().   MessageReceiption This message represents the reception of a V2X-message by a simulated node. The SimulationUnit with the id saved in the ReceivedV2XMessage object is scheduled for the processing of the message at the given simulation time. When simulation time reaches the reception time, the SimulationUnit will obtain the message from the message cache and hand it to all applications that implement the CommunicationApplication interface in the method SimulationUnit.processReceiveV2XMessage().   ApplicationInteraction While most other messages are specific to the a SimulationUnit, that then forwards the event to its applications, the ApplicationSpecificMessage is directly handed to all applications. Thereby, the SimulationUnit, whose applications shall receive the message can be specified. If this is not done, all applications of all units will get the message and have the opportunity to handle it.    ","date":1596672000,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1596672000,"objectID":"ba98bef533abd0bfde76ff58f6af3458","permalink":"https://www.eclipse.org/mosaic/docs/extending_mosaic/application_ambassador_details/","publishdate":"2020-08-06T00:00:00Z","relpermalink":"/mosaic/docs/extending_mosaic/application_ambassador_details/","section":"docs","summary":"The Application Simulator is completely implemented as an Eclipse MOSAIC Ambassador in Java. The main class ApplicationAmbassador is started by the RTI and creates different components, like the SimulationKernel singleton or the CentralNavigationComponent.","tags":null,"title":"Application Ambassador - Implementation Details","type":"docs"},{"authors":null,"categories":null,"content":"  ITEF is part of MOSAIC Extended.\nFor further information on licenses, feel free to contact us via mosaic@fokus.fraunhofer.de.\n  The Integrated Test and Evaluation Framework (ITEF) is a webtool for planning and evaluating vehicular communication scenarios. It is suited for field operational tests as well as simulations.\nITEF also offers a variety of visualization features, making a comparison of different vehicles or between equipped and unequipped vehicles easy. It is structured into 4 screens, whereas the following 3 screens are intended for the visualization.\nThe Replay screen (see Figure 1) is intended to be used for an initial overview of the test run. The main feature is the display of the vehicle movements on a map, while the player can be used to playback the movement situation. In this manner, the ITEF allows a location and time dependent evaluation of simulation test runs.\n ITEF Replay Screen   The Evaluate screen (see Figure 2) allows the detailed investigation of the correlations in a test run. The main feature of this screen is to display the behavior summarized over the whole run. The structure of this screen with is similar to the Replay screen. However, the focus here is on the detailed (statistical) summary of evaluated metrics.\n ITEF Evaluate Screen   Finally, the Statistics screen (see Figure 3) provides statistical evaluations of the test and simulation run. Currently, statistics on Vehicle Speed, Travel Time, Travel Distance and severalmore are supported.\n ITEF Statistics Screen   ","date":1557010800,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1557010800,"objectID":"90c70d06303c99232632c33c319ffb8b","permalink":"https://www.eclipse.org/mosaic/docs/visualization/itef/","publishdate":"2019-05-05T00:00:00+01:00","relpermalink":"/mosaic/docs/visualization/itef/","section":"docs","summary":"ITEF is part of MOSAIC Extended.\nFor further information on licenses, feel free to contact us via mosaic@fokus.fraunhofer.de.\n  The Integrated Test and Evaluation Framework (ITEF) is a webtool for planning and evaluating vehicular communication scenarios.","tags":null,"title":"Integrated Test and Evaluation Framework (ITEF)","type":"docs"},{"authors":null,"categories":null,"content":"OMNeT++ is a simulation platform for discrete-event systems. Even though it is primarily targeted at simulating computer networks and distributed systems, it cannot be used without any extensions for wireless communication. For this kind of simulations, external model frameworks have to be included. Currently, there are two prominent model frameworks which cover whole model suites for according focus of wireless research. These are the Mobility Framework and the INET Framework. As INET provides all models necessary for simulating Vehicle-2-X communication, it is selected for the integration to Eclipse MOSAIC.\nFor more information on the INET extension you should look closer on the website  .\n          Operating System GNU/Linux\n(Windows with mingw)    License GPL, free to use for academic use    Supported version(s) OMNeT++ 5.5 INET 4.1 http://www.omnetpp.org  https://inet.omnetpp.org      Installation There are two installation types of the MOSAIC OMNeT++ Federate:\n   Type Description     USER   This installation type addresses those who only want to use the OMNeT++ network simulator for simulations.\nNetwork configurations can also be adjusted.\nIf you install the federate with this installation type, OMNeT++ 5.5 and INET 4.1 will automatically be installed inside \u0026lt;mosaic\u0026gt;/bin/fed/omnetpp during the installation.   DEVELOPER   The installation for developers addresses those who want to make changes or extend the MOSAIC OMNeT++ Federate.\nThis installation type awaits that OMNeT++ 5.5 and INET 4.1 are already installed on your system and\n- PATH contains /path/to/omnetpp/bin\n- LD_LIBRARY_PATH contains /path/to/omnetpp/lib and /path/to/inet/src\n- C_INCLUDE_PATH contains /path/to/omnetpp/include and /path/to/inet/src     If you already have OMNeT++ 5.5 and INET 4.1 installed on your system, but you simply want to use OMNeT++ for simulations with Eclipse MOSAIC without developing further the MOSAIC OMNeT++ Federate, you may also choose the installation for developers to avoid multiple installations of OMNeT++ and INET on your system.\n  First of all, please make sure that you have the following libraries installed: unzip, tar, bison, flex, gcc, python, protoc\n The installation of the current version of the OMNeT++ Federate was tested with protobuf version 3.7.0.\nIt is recommended to install this version. Here you receive more information about how to install protobuf.\n  Follow the links and download the source code of OMNeT++, INET and the MOSAIC OMNeT++ Federate:\n   Software Version Link     OMNeT++ 5.5 https://omnetpp.org/download/     INET 4.1 https://github.com/inet-framework/inet/releases     MOSAIC OMNeT++ Federate 20.0 https://github.com/mosaic-addons/omnetpp-federate/releases      Available parameters of omnet_installer.sh:\n    Parameter Value Description     -t --installation-type \u0026lt;INSTALLATION_TYPE\u0026gt; Either USER or DEVELOPER.   -o --omnetpp \u0026lt;PATH_TO_OMNET_TGZ\u0026gt; Provide the archive containing the OMNeT++ source. You can obtain it from https://omnetpp.org/download/     -i --inet \u0026lt;PATH_TO_INET_TGZ\u0026gt; Provide the archive containing the inet source code. You can obtain it from https://inet.omnetpp.org/Download.html  . If not given, the inet-source files are downloaded by this installation script.   -f --federate \u0026lt;PATH_TO_FEDERATE_ZIP\u0026gt; Provide the archive containing the OMNeT++-federate and patches for coupling OMNeT++ to Eclipse MOSAIC. If not given, the omnetpp-federate is downloaded by this installation script.   -so --skip-omnetpp - Skip the installation of OMNeT++   -si --skip-inet - Skip the installation of INET   -q --quiet - Less output and no interaction required   -j --parallel \u0026lt;NUMBER_OF_THREADS\u0026gt; Enables make to use the given number of compilation threads.\nPer default your systems maximum is selected automatically.   -u --uninstall - Uninstalls the OMNeT++ federate   -h --help - Shows this usage screen    Installation for Users Run the installation script (this takes a few minutes):\ncd \u0026lt;mosaic\u0026gt;/bin/fed/omnetpp chmod +x omnet_installer.sh` ./omnet_install.sh \\ --installation-type USER \\ --omnetpp /path/to/omnetpp-5.5-src.tgz \\ --inet /path/to/inet-4.1-src.tgz \\ --federate /path/to/omnetpp-federate-20.0.zip  For the installation type USER the parameters -o, -i and -f are required.\nThe installation script should terminate with SUCESS: The MOSAIC OMNeT++ Federate was successfully installed. otherwise the installation failed.\nInstallation for Developers Run the installation script (this takes a few minutes):\ncd \u0026lt;mosaic\u0026gt;/bin/fed/omnetpp chmod +x omnet_installer.sh` ./omnet_install.sh \\ --installation-type DEVELOPER \\ --federate /path/to/omnetpp-federate-20.0.zip  For the installation type DEVELOPER the parameter -f is required.\nThe installation script should terminate with SUCCESS: The MOSAIC OMNeT++ Federate was successfully installed. otherwise the installation failed.\n Extending MOSAIC OMNeT++ Federate  OMNeT++ Federate Configuration To use OMNeT++ as network simulator in an Eclipse MOSAIC simulation, open \u0026lt;scenarioName\u0026gt;/scenario_config.json and enable OMNeT++:\n\u0026quot;federates\u0026quot;: { ... \u0026quot;omnetpp\u0026quot;: true, ... }  Now, when you run this scenario, Eclipse MOSAIC will automatically start the MOSAIC OMNeT++ Federate.\nThe main configuration of the MOSAIC OMNeT++ Federate is done within the configuration files omnetpp.ini and omnetpp_config.json in the scenario:\n└─ \u0026lt;scenario_name\u0026gt; └─ omnetpp ├─ omnetpp.ini ...................... OMNeT++ federate configuration file └─ omnetpp_config.json .............. Ambassador configuration file  The whole OMNeT++ specific configuration is done via the omnetpp.ini file. It covers static parts for the simulator coupling such as the specific Eclipse MOSAIC Event Scheduler and the ScenarioManager. Furthermore, logging configurations and the typical parameters for the communication layers (MAC, PHY and Radio Channel) are addressed. The communication parameters are different for vehicles and RSUs. Please refer to the OMNeT++ documentation on the OMNeT++ homepage for further information about the structure of the omnetpp.ini file.\nInstallation in Docker environment  This is an experimental feature. Please refer to our mailing list if you experience any problems.\n  This guide gives instructions to execute the OMNeT++ federate inside a docker container. If you already installed OMNeT++ on your machine following the steps before, you can skip this section.\nDocker is a new approach to execute software. More precisely, it \u0026ldquo;wraps software in a complete filesystem that contains everything it needs to run: code, runtime, system tools, and system libraries\u0026rdquo;. As a result, the software is executed within a container and its execution does not rely on the environment the container is running in.\nIn context of Eclipse MOSAIC, this approach allows to execute OMNeT++ within a docker container. The user does not need to manually install OMNeT++ and can even run OMNeT++ on Windows hosts.\n Install Docker ≥ 1.13 on your machine. To get everything to work, please make sure to execute the following steps depending on your operating system:  Windows - In the settings, share the drive where Eclipse MOSAIC is installed on. You may need to restart docker in the reset tab. Linux - Make sure your user account belongs to the unix-group docker. You may need to restart your machine.   Switch to the location of the Dockerfile in \u0026lt;mosaic\u0026gt;/bin/fed/omnetpp Execute the following command on command line:\ndocker build -t omnetpp-federate.\nThis could take a while to finish. Enter the name of the docker image etc/runtime.json in the omnetpp-section into the property dockerImage:  \u0026quot;federates\u0026quot;: [ ... { \u0026quot;id\u0026quot;: \u0026quot;omnetpp\u0026quot;, \u0026quot;dockerImage\u0026quot;: \u0026quot;omnetpp-federate\u0026quot;, ... }, ... ]  ","date":1557010800,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1557010800,"objectID":"208d551c9e8045f1304b3efe6800d7dd","permalink":"https://www.eclipse.org/mosaic/docs/simulators/network_simulator_omnetpp/","publishdate":"2019-05-05T00:00:00+01:00","relpermalink":"/mosaic/docs/simulators/network_simulator_omnetpp/","section":"docs","summary":"OMNeT++ is a simulation platform for discrete-event systems. Even though it is primarily targeted at simulating computer networks and distributed systems, it cannot be used without any extensions for wireless communication.","tags":null,"title":"Network Simulator OMNeT++","type":"docs"},{"authors":null,"categories":null,"content":"The ns-3 is a discrete-event network simulator that was developed as a replacement for the popular network simulator 2 (ns-2) and mainly focuses upon improving the core architecture, software integration, models, and educational components for real-world network devices and protocols. It simulates both unicast and multicast protocols and is used extensively in research on mobile ad-hoc networks.\nRegardless, ns-2 still remains in active use and will continue to be maintained in the near future. For Eclipse MOSAIC coupling, only ns-3 will be available.\nLike other network simulators, ns-3 has a relatively steep learning curve, especially compared to GUI- based simulators. If you have no prior experience with ns-3, we recommend familiarizing yourself with the ns-3 simulation environment and the ns-3 simulation basics first. The ns-3 documentation can be found under: https://www.nsnam.org/documentation\nTo take your first steps with ns-3, you might want to download 2 the latest version, build a copy of ns-3 (it uses the Python-based build-system waf) and take a look at the examples, that are shipped within most of the ns-3 source code repositories and packages. You might also examine the simulation output and try to adjust it.\nTypically, a ns-3 user will work under a Linux environment. For those running under Windows, there do exist environments which simulate the Linux environment to various degrees. The ns-3 project has in the past (but not presently) supported the Cygwin environment for these users (see http://www.cygwin.com for details on downloading). MiniGW is presently not officially supported, however there are also some people who managed to use it with ns-3. For detailed information of how to set up ns-3, please refer to their Wiki: https://www.nsnam.org/wiki/Installation\nFor more information on how to set up ns-3 with Eclipse MOSAIC, please just refer to the following section. We prepared an installation script, which manages most of the required work.\n As stated above, ns-3 is primarily developed on and for GNU/Linux platforms. Since Windows is such a widely used platform and Cygwin is not a perfect emulation of any Linux, we highly recommended for non-Linux users to consider the installation of a Linux virtual machine with a virtual machine environment, such as VMware or VirtualBox.\n      Software information     Developer(s) Tom Henderson, Mathieu Lacage, George Riley, Mitch Watrous, Gustavo Carneiro, Tommaso Pecorella and others   Written in C++ (core) and Python (bindings)   Operating system GNU/Linux FreeBSD Mac OS X   License Free software: GNU GPLv2   Website http://www.nsnam.org/   Supported version(s) 3.28   Dependencies libprotobuf 3.3.0    libxml2    libsqlite3   Deployed in MOSAIC all-in-one no (and need a patch to link)    ns3-ambassador folder structure └─ \u0026lt;scenario_name\u0026gt; └─ ns3 ├─ ns3_config.json ................. Ambassador configuration file ├─ configTechnologies.xml ...........ns-3 federate configuration file └─ confWifi.xml .....................ns-3 federate configuration file  Installation Eclipse MOSAIC offers support for the current stable release of ns-3 (3.28), that was released in March 2018. Older versions of ns-3 (prior to 3.28) are not supported. However, also for newer versions we cannot guarantee the correct operation. The coupling to Eclipse MOSAIC is designed in a manner of minimal code changes on the ns-3 simulator itself to keep the update capabilities for future versions.\nPrerequisites For GNU/Linux platforms, the minimal requirements to run basic simulations are a gcc or clang compiler and a Python interpreter. At least you need the following packages to be installed:\nMinimum requirement:\ngcc g++ python python-dev  For a complete list of required packages for different distributions, please refer to the ns-3 installation guide: https://www.nsnam.org/wiki/Installation\nPlease make sure the following libraries are installed before running the installation script:\n libxml2 libsqlite3 libprotobuf 3.3.0  Run the installation script  ns-3 requires several packages to be installed on your computer. You will need to ensure, that all required libraries are present on your system before proceeding. You may need superuser permissions to install packages.\n   If your local protobuf version does not fit the required one, the installation may fail with an error. In that case, you can run the install script with the -p flag. This will rebuild the protobuf files during installation and allow it to proceed correctly.\n  To ease the installation of ns-3 for Eclipse MOSAIC, the installation process has been delegated to an installation script, that can be found in the associated ns-3 federate folder.\nns3-ambassador federate folder structure:\n└─ mosaic/bin/fed/ns3 └─ ns3 ├─ Dockerfile.sh ....................Dockerfile for ns-3 federate └─ ns3_installer.sh ................ Installation script for ns-3  The ns-3 installation script accomplishes the following tasks:\n Download ns-3 tarball from the official sources Download the ns-3 federate for Eclipse MOSAIC. Apply a patch to ns-3 in order to make it work with Eclipse MOSAIC. Add the ns-3 federate to the waf build system. Configure and build the patched ns-3 with the ns-3 federate.  In order to start the simulation, the following steps need to be performed:\n Set up the confWifi.xml-file in the scenario folder (see section Configuration  ). An example confWifi.xml - file is shipped with the Tiergarten scenario. For reasonable result logging, the logger-configuration in mosaic/etc/logback.xml has to be adapted to support the ns-3 ambassador and federate. At last ns-3 has to be activated in the mosaic_config.xml and the simulation can be started.  Installation in Docker environment  This is an experimental feature. Please refer to our mailing list if you experience any problems.\n  This guide gives instructions to execute the ns-3 federate inside a docker container. If you already installed ns-3 on your machine following the steps before, you can skip this section.\nDocker is a new approach to execute software. More precisely, it \u0026ldquo;wraps software in a complete filesystem that contains everything it needs to run: code, runtime, system tools, and system libraries\u0026rdquo;. As a result, the software is executed within a container and its execution does not rely on the environment the container is running in.\nIn context of Eclipse MOSAIC, this approach allows to execute ns-3 within a docker container. The user does not need to manually install ns-3 and can even run ns-3 on Windows hosts.\n Install Docker ≥ 1.13 on your machine. To get everything to work, please make sure to execute the following steps depending on your operating system:  Windows - In the settings, share the drive where Eclipse MOSAIC is installed on. You may need to restart docker in the reset tab. Linux - Make sure your user account belongs to the unix-group docker. You may need to restart your machine.   Switch to the location of the Dockerfile in \u0026lt;mosaic\u0026gt;/bin/fed/ns3 Execute the following command on command line:\ndocker build -t ns3-federate.\nThis could take a while to finish. Enter the name of the docker image etc/runtime.json in the ns3-section into the property dockerImage:  \u0026quot;federates\u0026quot;: [ ... { \u0026quot;id\u0026quot;: \u0026quot;ns3\u0026quot;, \u0026quot;dockerImage\u0026quot;: \u0026quot;ns3-federate\u0026quot;, ... }, ... ]  You can test the installation of your docker image with the Tiergarten scenario, by activating ns3 in the scenario_config.json.\nConfiguration The whole ns-3 specific configuration is done via the confWifi.xml and configTechnologies.xml files.\nconfWifi.xml:\n\u0026lt;?xml version=\u0026quot;1.0\u0026quot; encoding=\u0026quot;UTF-8\u0026quot; standalone=\u0026quot;no\u0026quot;?\u0026gt; \u0026lt;wifi\u0026gt; \u0026lt;!-- IPv4 address generator --\u0026gt; \u0026lt;ipConfiguration\u0026gt; \u0026lt;ip address=\u0026quot;192.168.0.0\u0026quot; mask=\u0026quot;255.255.0.0\u0026quot;/\u0026gt; \u0026lt;/ipConfiguration\u0026gt; \u0026lt;!-- Calculate a propagation delay --\u0026gt; \u0026lt;propagationDelayModel\u0026gt; \u0026lt;delay model= \u0026quot;ns3::NonePropagationDelayModel\u0026quot;/\u0026gt; \u0026lt;/propagationDelayModel\u0026gt; \u0026lt;!-- Modelize the propagation loss through a transmission medium --\u0026gt; \u0026lt;propagationLossModel\u0026gt; \u0026lt;loss model= \u0026quot;ns3::FriisPropagationLossModel\u0026quot;/\u0026gt; \u0026lt;/propagationLossModel\u0026gt; \u0026lt;wifiConfiguration\u0026gt; \u0026lt;!-- Create non QoS-enabled MAC layers --\u0026gt; \u0026lt;wifiMac property=\u0026quot;type\u0026quot; value=\u0026quot;ns3::AdhocWifiMac\u0026quot;/\u0026gt; \u0026lt;!-- Wifi PHY mode --\u0026gt; \u0026lt;wifiManager property=\u0026quot;phyMode\u0026quot; value=\u0026quot;OfdmRate54Mbps\u0026quot;/\u0026gt; \u0026lt;!-- Wifi manager --\u0026gt; \u0026lt;wifiManager property=\u0026quot;type\u0026quot; value=\u0026quot;ns3::ConstantRateWifiManager\u0026quot;/\u0026gt; \u0026lt;!-- The energy of a received signal should be higher than this threshold (dbm) to allow the PHY layer to detect the signal --\u0026gt; \u0026lt;wifiPhy property=\u0026quot;EnergyDetectionThreshold\u0026quot; value=\u0026quot;-81.0\u0026quot;/\u0026gt; \u0026lt;!-- The energy of a received signal should be higher than this threshold (dbm) to allow the PHY layer to declare CCA BUSY state --\u0026gt; \u0026lt;wifiPhy property=\u0026quot;CcaMode1Threshold\u0026quot; value=\u0026quot;-99.0\u0026quot;/\u0026gt; \u0026lt;!-- Transmission gain (dB) --\u0026gt; \u0026lt;wifiPhy property=\u0026quot;TxGain\u0026quot; value=\u0026quot;0.0\u0026quot;/\u0026gt; \u0026lt;!-- Reception gain (dB) --\u0026gt; \u0026lt;wifiPhy property=\u0026quot;RxGain\u0026quot; value=\u0026quot;0.0\u0026quot;/\u0026gt; \u0026lt;!-- Number of transmission power levels available between TxPowerStart and TxPowerEnd included --\u0026gt; \u0026lt;wifiPhy property=\u0026quot;TxPowerLevels\u0026quot; value=\u0026quot;1\u0026quot;/\u0026gt; \u0026lt;!-- Maximum available transmission level (dbm) --\u0026gt; \u0026lt;wifiPhy property=\u0026quot;TxPowerEnd\u0026quot; value=\u0026quot;17.0\u0026quot;/\u0026gt; \u0026lt;!-- Minimum available transmission level (dbm) --\u0026gt; \u0026lt;wifiPhy property=\u0026quot;TxPowerStart\u0026quot; value=\u0026quot;17.0\u0026quot;/\u0026gt; \u0026lt;!-- Loss (dB) in the Signal-to-Noise-Ratio due to non-idealities in the receiver --\u0026gt; \u0026lt;wifiPhy property=\u0026quot;RxNoiseFigure\u0026quot; value=\u0026quot;0.0\u0026quot;/\u0026gt; \u0026lt;!-- Channel center frequency = Channel starting frequency + 5 MHz * (nch - 1) --\u0026gt; \u0026lt;wifiPhy property=\u0026quot;ChannelNumber\u0026quot; value=\u0026quot;1\u0026quot;/\u0026gt; \u0026lt;/wifiConfiguration\u0026gt; \u0026lt;/wifi\u0026gt;  The IP configuration information includes the network address and network mask. The ns-3 propagation module defines two generic interfaces, namely PropagationLossModel and PropagationDelayModel, for the modelling of propagation loss respectively propagation delay.\nIn the default confWifi.xml, the Wi-Fi device uses the ns-3 standard propagation delay model ns3::ConstantSpeedPropagationDelayModel and the ns-3 standard propagation loss model ns3::FriisPropagationLossModel. Radio propagation models in ns-3 can easily be exchanged with the ns-3 class registration system (see the ns-3 documentation for details). The Wi-Fi configuration includes additional parameters, like sending power and antenna gain.\nconfigTechnologies.xml:\n\u0026lt;?xml version=\u0026quot;1.0\u0026quot; encoding=\u0026quot;UTF-8\u0026quot; standalone=\u0026quot;no\u0026quot;?\u0026gt; \u0026lt;ns3Configuration\u0026gt; \u0026lt;installers\u0026gt; \u0026lt;installer type=\u0026quot;ns3::WifiVehicleInstaller\u0026quot; name=\u0026quot;WifiVehicle\u0026quot; file=\u0026quot;confWifi.xml\u0026quot; default=\u0026quot;true\u0026quot; /\u0026gt; \u0026lt;installer type=\u0026quot;ns3::MobilityModelInstaller\u0026quot; name=\u0026quot;Mobility\u0026quot; default=\u0026quot;true\u0026quot; /\u0026gt; \u0026lt;/installers\u0026gt; \u0026lt;/ns3Configuration\u0026gt;  The configuration manager of the ns-3 federate defines, which installer should be loaded for the Wi-Fi device (refering to the confWifi.xml) and the mobility model. Usually, you don’t need to take any changes and simply use the default configuration file, that ships with the ns-3 federate.\n","date":1557010800,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1557010800,"objectID":"10a4ba934e0981b530dd053b83c60773","permalink":"https://www.eclipse.org/mosaic/docs/simulators/network_simulator_ns3/","publishdate":"2019-05-05T00:00:00+01:00","relpermalink":"/mosaic/docs/simulators/network_simulator_ns3/","section":"docs","summary":"The ns-3 is a discrete-event network simulator that was developed as a replacement for the popular network simulator 2 (ns-2) and mainly focuses upon improving the core architecture, software integration, models, and educational components for real-world network devices and protocols.","tags":null,"title":"Network Simulator ns-3","type":"docs"},{"authors":null,"categories":null,"content":"  The 3D visualization PHABMap is part of MOSAIC Extended.\nFor further information on licenses, feel free to contact us via mosaic@fokus.fraunhofer.de.\n  The Eclipse MOSAIC 3D Visualization Tool is based on the PHABMACS vehicle simulator and uses the same 3D engine and models to visualize vehicle movements and various events which occur during the simulation. Next to the road network, which can be optionally rendered by the visualizer, the following units and events are visualized:\n Vehicle movements coming from the traffic simulation Road Side Units at their defined location V2X-messages sent via cellular communication (indicated as green circles) V2X-messages sent via ITS-G5 communication (indicated as blue circles) V2X-messages received by vehicles (indicated as red circles)   The 3D visualization tool PHABMap displaying events from the simulation   ","date":1557010800,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1557010800,"objectID":"262992c33ea9dc690e168169b920406b","permalink":"https://www.eclipse.org/mosaic/docs/visualization/phabmap/","publishdate":"2019-05-05T00:00:00+01:00","relpermalink":"/mosaic/docs/visualization/phabmap/","section":"docs","summary":"The 3D visualization PHABMap is part of MOSAIC Extended.\nFor further information on licenses, feel free to contact us via mosaic@fokus.fraunhofer.de.\n  The Eclipse MOSAIC 3D Visualization Tool is based on the PHABMACS vehicle simulator and uses the same 3D engine and models to visualize vehicle movements and various events which occur during the simulation.","tags":null,"title":"3D Visualization (PHABMap)","type":"docs"},{"authors":null,"categories":null,"content":"The Simulation of Urban Mobility (SUMO) simulator is an open source microscopic, multi-modal traf- fic simulation package which is developed by the Institute of Transportation research at the German Aerospace Centre. It is designed to handle large road networks faster than real-time. Each vehicle has an own route and is simulated individually. To simulate the movements of the vehicles on the network, a model is used that uses discrete time steps of e.g. 1 s. Thousands of vehicles can be simulated in real time on a desktop PC, including simulation of traffic lights, right-of-way rules, and lane changing models. Simulations can either run via the command line or are visualized using the openGL-API (SUMO-GUI). SUMO networks are created by importing other formats, such as OpenStreetMap data, Shapefiles or TIGE-maps; or by generating artificial networks. Furthermore, vehicle routes, based on different routing paradigms, can be computed.\nSUMO and Eclipse MOSAIC We have integrated the traffic simulator SUMO to be able to simulate heterogeneous driving vehicles and a set of vehicles that have a predefined routes based on an imported roadmap. Additionally, during the runtime of a simulation, it is possible that routes of simulated vehicles are changed and that vehicle positions are extracted at arbitrary points in time. The integration of SUMO into a Eclipse MOSAIC based simulation is illustrated in the following figure. The integrated Traffic Control Interface (TraCI) Server offers an interface to exchange commands and positions using a socket interface with a proprietary byte protocol. Analogous to the TraCI Server, a TraCI Client is implemented that is integrated in an ambassador implementing the TraCI protocol. Therefore, SUMO can be integrated without modifications.\n SUMO connected to Eclipse MOSAIC   During a simulation run, per default SUMO is paused and TraCI is listening for commands. After each advanced time grant, SUMO offers the new vehicle positions which are broadcast by its ambassador to other federates. Furthermore, if the ambassador receives a request to change the route of a specific vehicle, it is forwarded to SUMO. Thus, at the next time-advancement, the new route is integrated.\nSimulation of Vehicles For each vehicle which has been defined in the mapping configuration, a VehicleRegistration interaction is sent to the SumoAmbassador which adds those vehicles to the simulation via TraCI. Furthermore, vehicle data is subscribed which is updated with every simulation step. After each step of the simulation this data is bundled into a VehicleInfo object which is distributed among other ambassadors within the VehicleUpdates interaction. The following data is available for each vehicle:\n Position Speed, Acceleration, Heading, Slope State of vehicle signals (e.g. turn indicators) Emission dispersion (CO2, NOX, etc.) Fuel consumption Information about the road the vehicle is driving on (road position) Id of the route  Traffic lights in SUMO Depending on which light is active (red, yellow or green), every traffic light got different phases. In theory, any combination of dis- or enabled lights is possible, but SUMO only handles combinations which make sense. In SUMOs traffic light concept every traffic light got a bitset of the status of each phase. Every bitset is a combination as mentioned above. When a car approaches a junction, it gets the actual bitset (combination) of the traffic light. To explain the code, an example is given:\n\u0026lt;tl-logic type=\u0026quot;static\u0026quot;\u0026gt; \u0026lt;key\u0026gt;0\u0026lt;/key\u0026gt; \u0026lt;subkey\u0026gt;my program\u0026lt;/subkey\u0026gt; \u0026lt;phaseno\u0026gt;8\u0026lt;/phaseno\u0026gt; \u0026lt;offset\u0026gt;0\u0026lt;/offset\u0026gt; \u0026lt;phase duration=\u0026quot;31\u0026quot; state=\u0026quot;GGggrrrrGGggrrrr\u0026quot;/\u0026gt; \u0026lt;phase duration=\u0026quot;5\u0026quot; state=\u0026quot;yyggrrrryyggrrrr\u0026quot;/\u0026gt; \u0026lt;phase duration=\u0026quot;6\u0026quot; state=\u0026quot;rrGGrrrrrrGGrrrr\u0026quot;/\u0026gt; \u0026lt;phase duration=\u0026quot;5\u0026quot; state=\u0026quot;rryyrrrrrryyrrrr\u0026quot;/\u0026gt; \u0026lt;phase duration=\u0026quot;31\u0026quot; state=\u0026quot;rrrrGGggrrrrGGgg\u0026quot;/\u0026gt; \u0026lt;phase duration=\u0026quot;5\u0026quot; state=\u0026quot;rrrryyggrrrryygg\u0026quot;/\u0026gt; \u0026lt;phase duration=\u0026quot;6\u0026quot; state=\u0026quot;rrrrrrGGrrrrrrGG\u0026quot;/\u0026gt; \u0026lt;phase duration=\u0026quot;5\u0026quot; state=\u0026quot;rrrrrryyrrrrrryy\u0026quot;/\u0026gt; \u0026lt;/tl-logic\u0026gt;  This example shows the traffic light program of one junction. It shows the different status’ of each light of each traffic signal, which are positioned on the junction. In this example every string of a phase e.g. \u0026ldquo;GGggrrrrGGggrrrr\u0026rdquo; (first phase) got 16 characters. Every char stands for one light on the junction. On this junction are four traffic lights with four signals each. To understand the different status of each light in one period (8 phases) the program should be read from top to the bottom. It is possible to change or create your own program by editing the .net file with the tool Netedit.\nHandling of traffic lights in Eclipse MOSAIC After the TraCI connection has been established, all available traffic light groups are read out of SUMO via TraCI. This information is packed into the three classes TrafficLightGroup, TrafficLightSignal, and TrafficLightPhase. While a traffic light group contains a list of signals which control one intersec- tion (which can consist of several nodes), a list of all existing traffic light groups is sent to the RTI via a ScenarioTrafficLightRegistration interaction.\nTraCI Client Implementation The SumoAmbassador communicates with the federate (SUMO process) via TraCI. In this socket based communication protocol, the server (SUMO) listens to commands and responds accordingly.\nEach message send to SUMO consist of a header and the command or result message, according to the following scheme:\n 0 7 8 15 +--------------------------------------+ | Message Length including this header | +--------------------------------------+ | (Message Length, continued) | +--------------------------------------+ \\ | Length | Identifier | | +--------------------------------------+ \u0026gt; Command / Result_0 | Command / Result_0 content | | +--------------------------------------+ / ... +--------------------------------------+ \\ | Length | Identifier | | +--------------------------------------+ \u0026gt; Command / Result_n -1 | Command / Result_n-1 content | | +--------------------------------------+ /  A more detailed description can be found here: http://sumo.dlr.de/wiki/TraCI/Protocol  Commands Each TraCI command is identified by an command identifier. For example, the command 0xC4 is used to change the state of a vehicle. Most of the commands need further specification, such as the parameter of the vehicle which is required to be changed. Those parameters are usually accessed by variable identifiers (e.g. 0x40 addresses the speed of an entity). A full list of commands and variables supported by TraCI can be found here: http://sumo.dlr.de/wiki/TraCI  Here is an example of a command message to change the speed of the vehicle \u0026ldquo;veh_0\u0026rdquo; to 14m/s:\n 0 7 8 15 23 24 31 +-----------------------------------------------------------------------------+ | 25 (Message length) | +-----------------------------------------------------------------------------+ | 21 (Length) | 0xC4 (Command) | 0x40 (Variable) | +-----------------------------------------------------------------------------+ 5 (String length as 4 Byte Integer) | \u0026quot;v\u0026quot; | +-----------------------------------------------------------------------------+ | \u0026quot;e\u0026quot; | \u0026quot;h\u0026quot; | \u0026quot;_\u0026quot; | \u0026quot;0\u0026quot; | +-----------------------------------------------------------------------------+ | 0x0B (Double type)| 40.0 (8 Byte Double) +-----------------------------------------------------------------------------+ +-----------------------------------------------------------------------------+ | +-------------------+  AbstractTraciCommand In the TraCI client implementation of the SumoAmbassador the whole construction of messages is done in the class AbstractTraciCommand. The message header containing the message and command lengths is constructed automatically as well as all parameters defined by the specific command. To achieve this, each class which extends the AbstractTraciCommand needs to define the command, the variable and all parameters which are required for the specific command:\nprotected VehicleSetSpeed() { super(TraciVersion.LOWEST); write() .command(0xC4) // = change vehicle state .variable(0x04) // = set speed of entity .writeStringParam() // = vehicle id .writeDoubleParamWithType(); // = speed value }  This example shows the command implementation for setting the speed for a vehicle. In the constructor, the write methods provides a builder-like construct allowing to define the command, the variable, and all parameters which are later passed dynamically to the command. Here, the command is specified as 0xC4 (= change vehicle state) and the variable as 0x04 (= speed of the entity). Furthermore, two parameters are defined: The first string parameter represents the ID of the vehicle, the second double parameter defines the speed value to be set (according to http://sumo.dlr.de/wiki/TraCI/Change_Vehicle_State  ). Note, the order of the specified command contents is from crucial importance. E.g. the command must always be specified before the variable, and the variable before all parameters.\nAll parameters defined in the constructor (here: [String, Double] ), need to be assigned with values as soon as the command is executed. For this purpose, the command implementation needs to call the method execute of the super class with the parameter values in the specified order:\npublic void setSpeed(TraciConnection traciCon, String vehicleId, double speedValue) { super.execute(traciCon, vehicleId, value); }  Within the execute method, the AbstractTraciCommand constructs the whole message and sends it to the TraCI server (SUMO). Furthermore, the AbstractTraciCommand also reads the response, extracts the status of the response (successful or error) and reads all values returned by the server. Usually, commands which changes the state of an entity only (like VehicleSetSpeed) do not respond with complex results. However, a command which wants to retrieve a value of an entity needs to read out the result from the response (e.g. VehicleGetRouteId which returns the current route identifier of the vehicle). For this purpose, each command needs to specify how the response should be handled:\nprotected VehicleGetRouteId() { super(TraciVersion.LOWEST); write() .command(0xA4) // = retrieve vehicle state .variable(0x53) // = route id of entity .writeStringParam(); // = write vehicle id read() .skipBytes(2) // = skip command and variable in response .skipString() // = skip vehicle id, not relevant .readStringWithType(); // = read route id  This example shows the command implementation for getting the route id of a vehicle. As well as write, the method read returns a builder-like construct which provides methods to define how the response is handled. Here, the first two bytes of the response should be skipped, as well as the string which follows afterwards. The value the command is interested in is the following string value which holds the id of the route. By using the method readStringWithType the string is read out and is passed to the method constructResult which needs to be implemented by the command as well:\npublic String getRouteId(TraciConnection con, String vehicle) { return super.executeAndReturn(con, vehicle); } @Override protected String constructResult(Status status, Object... objects) { return (String) objects[0]; }  In this simple case the result of the command consists of one result object only (the route id). Therefore, it is just extracted from the array of result objects and directly returned.\nWriting parameters In order to write parameters and read results according to the specification of the protocol, several reader and writer implementations exist. For parameters to be written in the command various writers exists to write single bytes, strings, integers, and doubles, or special writers for writing lists. The same is for readers.\nIn the following example, the IntegerTraciWriter is shown:\npublic class IntegerTraciWriter extends AbstractTraciParameterWriter\u0026lt;Integer\u0026gt; { public IntegerTraciWriter() { super(4); } public IntegerTraciWriter(int value) { super(4, value); } @Override public int getVariableLength(Integer argument) { return getLength(); } @Override public void write(DataOutputStream out) throws IOException { out.writeInt(value); } @Override public void writeVariableArgument(DataOutputStream out, Integer argument) { out.writeInt(argument); } }  Each writer has two tasks. Firstly, it needs to determine the length of the parameter value. For example, an integer parameter is always 4 bytes long, whereas the length of a string parameter depends on the size of the argument. Therefore, each writer needs to be able to determine the variable length according to a given value. Secondly, it needs to write out the actual value into the DataOutputStream (which represents the channel to the TraCI server). Furthermore is each writer able to write fixed values, such as the command identifier which does not change, or variable arguments, such as the vehicle id.\nReading results In the following example, the IntegerTraciReader is shown:\npublic class IntegerTraciReader extends AbstractTraciResultReader\u0026lt;Integer\u0026gt; { public IntegerTraciReader() { super(null); } public IntegerTraciReader(Matcher\u0026lt;Integer\u0026gt; matcher) { super(matcher); } @Override protected Integer readFromStream(DataInputStream in) throws IOException { return readInt(in); } }  A reader has three tasks. Firstly, it reads out a value from the DataInputStream (which represents the response channel to the TraCI client) according to the protocol specification. For example, an integer can be read out directly, while a string requires several single reading operations. Secondly, the reader needs to take track of the number of bytes it has read in total. To achieve this it is recommended to use the provided methods of the super class, such as readInt, readString, or readByte .However, if values need to be read directly from the DataInputStream, the protected field numBytesRead must always be increased accordingly. Thirdly, the reader needs to define if the read out value fulfils certain requirements. Such requirement can be, that a certain value is expected. In this case, a matcher might be passed to the super constructor.\nAccessing the commands For each command, only one object should be instantiated during runtime. To achieve this, the CommandRegister is used. This class stores a command once it is created returns only one instance per command class:\nfinal RouteAdd routeAddCommand = commandRegister.getOrCreate(RouteAdd.class); //... do something  However, commands should not be accessed directly in the code, but rather using the various facades available:\n TraciRouteFacade - Route specific command calls, such as addRoute and getRouteEdges . TraciSimulationFacade - Provides methods to control the simulation, such as simulateStep . TraciTrafficLightFacade - Provides methods to get or set values for traffic lights. TraciVehicleFacade - Provides methods to get or set values for vehicles. All those facades can be accessed via the TraciClient.  Exception handling Exceptions are thrown and handled as following:\n  If a command results in a status response with the status code Error, a TraciCommandException is thrown. If this exception is thrown, the TraCI connection is still alive and can be used for further commands. The facades decide how to handle this exception then and may throw an InternalFederateException or log a warning message.\n  If a command could not be written properly, or the result could not be read out as wished, an InternalFederateException is thrown and an Emergency Exit is initiated, which eventually shuts down the TraCI connection. This also happens if a reader or writer throws any kind of Exception.\n  Version handling With future releases of SUMO new TraCI commands will emerge. To achieve downward compatibility each command can define the lowest TraCI Version it supports. For example, a command which was introduced with SUMO 0.30.0 and is annotated accordingly, would be skipped automatically if the version of the TraCI server is lower. However, this concept has not been tested yet properly.\n","date":1557010800,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1557010800,"objectID":"619eca86fee9768692c3090a256ba49b","permalink":"https://www.eclipse.org/mosaic/docs/extending_mosaic/sumo_ambassador_details/","publishdate":"2019-05-05T00:00:00+01:00","relpermalink":"/mosaic/docs/extending_mosaic/sumo_ambassador_details/","section":"docs","summary":"The Simulation of Urban Mobility (SUMO) simulator is an open source microscopic, multi-modal traf- fic simulation package which is developed by the Institute of Transportation research at the German Aerospace Centre.","tags":null,"title":"Sumo Ambassador Implementation","type":"docs"},{"authors":null,"categories":null,"content":"The Simple Network Simulator (SNS) aims to provide simple and fast capabilities for the transmission of V2X-messages using Ad hoc communication. In order to stay performant the simulator makes abstractions in certain places. Those abstractions will be discussed later on.\nConfiguration The SNS offers some configurability regarding the way transmissions are simulated.\nMain Configuration:\n   Parameter Description type Default Value     maximumTtl Defines the upper bound for the amount of hops a message can make. (Note: messages can have individual ttl\u0026rsquo;s) int 10   singlehopRadius Fallback radius to be used for transmission, if no radius is defined in the AdhocConfiguration double 509.4   singlehopDelay A delay configuration for the direct communication between two nodes. ( See here  ) Delay `ConstantDelay |   singlehopTransmission This contains the transmission configurations for lossProbability and maxRetries. CTransmission n/a   adhocTransmissionModel A class extending AdhocTransmissionModel, this will decide the logic for transmissions. AdhocTransmissionModel SimpleAdhoc TransmissionModel     On default the SNS will use the SimpleAdhocTransmissionModel with a ConstantDelay using 0 as delay. This means it usually makes sense to specify the AdhocTransmissionModel explicitly and use a more realistic Delay. Example Configuration:\n { \u0026quot;maximumTtl\u0026quot;: 20, \u0026quot;singlehopRadius\u0026quot;: 300.5, \u0026quot;singlehopDelay\u0026quot;: { \u0026quot;type\u0026quot;: \u0026quot;SimpleRandomDelay\u0026quot;, \u0026quot;steps\u0026quot;: 5, \u0026quot;minDelay\u0026quot;: \u0026quot;1.5 ms\u0026quot;, \u0026quot;maxDelay\u0026quot;: \u0026quot;2.5 ms\u0026quot; }, \u0026quot;singlehopTransmission\u0026quot;: { \u0026quot;lossProbability\u0026quot;: 0.0, \u0026quot;maxRetries\u0026quot;: 0 }, \u0026quot;adhocTransmissionModel\u0026quot;: { \u0026quot;type\u0026quot;: \u0026quot;SimpleAdhocTransmissionModel\u0026quot;, \u0026quot;simpleMultihopDelay\u0026quot;: { \u0026quot;type\u0026quot;: \u0026quot;GammaRandomDelay\u0026quot;, \u0026quot;minDelay\u0026quot;: \u0026quot;10 ms\u0026quot;, \u0026quot;expDelay\u0026quot;: \u0026quot;30 ms\u0026quot; }, \u0026quot;simpleMultihopTransmission\u0026quot;: { \u0026quot;lossProbability\u0026quot;: 0.1, \u0026quot;maxRetries\u0026quot;: 2 } } }   Read the detailed documentation of the SNS Configuration.\n  Transmission Logic SNS differentiates between two types of Ad hoc transmissions, geographically- and topologically-scoped transmissions, which generally are abbreviated with GeoCast and TopoCast respectively.\nGeoCasts are limited to BroadCasts. Accordingly, there is no explicit addressing of receivers (other than 255.255.255.255), instead a destination area is specified. However, GeoCasts allow for multihop forwarding.\nTopoCasts on the other hand use means of IPv4 addressing to transmit messages. Since the SNS was not build to simulate transmissions using complex topology-constructs, TopoCasts are limited to transmissions with a single hop. However, TopoCasts support BroadCasts and UniCasts (we are omitting Anycasts). Most transmissions in the Ad hoc domain will be some form of Broadcast, meaning every reachable entity is eligible to receive a message.\n#mermaid-1603209753374{font-family:\"trebuchet ms\",verdana,arial;font-size:16px;fill:#333;}#mermaid-1603209753374 .error-icon{fill:#552222;}#mermaid-1603209753374 .error-text{fill:#552222;stroke:#552222;}#mermaid-1603209753374 .edge-thickness-normal{stroke-width:2px;}#mermaid-1603209753374 .edge-thickness-thick{stroke-width:3.5px;}#mermaid-1603209753374 .edge-pattern-solid{stroke-dasharray:0;}#mermaid-1603209753374 .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-1603209753374 .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-1603209753374 .marker{fill:#333333;}#mermaid-1603209753374 .marker.cross{stroke:#333333;}#mermaid-1603209753374 svg{font-family:\"trebuchet ms\",verdana,arial;font-size:16px;}#mermaid-1603209753374 .label{font-family:\"trebuchet ms\",verdana,arial;color:#333;}#mermaid-1603209753374 .label text{fill:#333;}#mermaid-1603209753374 .node rect,#mermaid-1603209753374 .node circle,#mermaid-1603209753374 .node ellipse,#mermaid-1603209753374 .node polygon,#mermaid-1603209753374 .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-1603209753374 .node .label{text-align:center;}#mermaid-1603209753374 .node.clickable{cursor:pointer;}#mermaid-1603209753374 .arrowheadPath{fill:#333333;}#mermaid-1603209753374 .edgePath .path{stroke:#333333;stroke-width:1.5px;}#mermaid-1603209753374 .flowchart-link{stroke:#333333;fill:none;}#mermaid-1603209753374 .edgeLabel{background-color:#e8e8e8;text-align:center;}#mermaid-1603209753374 .edgeLabel rect{opacity:0.5;background-color:#e8e8e8;fill:#e8e8e8;}#mermaid-1603209753374 .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-1603209753374 .cluster text{fill:#333;}#mermaid-1603209753374 div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:\"trebuchet ms\",verdana,arial;font-size:12px;background:hsl(80,100%,96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-1603209753374:root{--mermaid-font-family:\"trebuchet ms\",verdana,arial;}#mermaid-1603209753374 flowchart{fill:apa;}TopoCastGeoCastYesYesYesNoYesNoV2X-TransmissionTransmission TypeBroadcast\nor Unicast?Broadcast?Simulate TopoCast using\nsinglehop configuration.Simple transmission\nmodel?Simulate transmission using\nsimpleMultihopDelay.Sender directly able to reach\ndestination area?Flooding in destination areaGreedy Forwarding to reach area,\nthen flooding in destination areay.  This flowchart tells how different types of messages are handled internally.   TopoCasts The only way of directly addressing entities is a SingleHopUniCast (see figure below), the sender will try to address an entity in its transmission range.   SingleHopUniCast: The RSU is directly addressing the green vehicle.   The counterpart to that is a SingleHopBroadCast (see figure below), this form of transmission is commonly used for CAMs (Cooperative Awareness Messages) and other types of intermediate warning messages to all entities in transmission range.\n  SingleHopBroadCast: The RSU is addressing all units in transmission range.   GeoCasts As already explained, GeoCasts do not support direct addressing, so there is no form of UniCast. Instead of addressing entities, GeoCasts specify a destination area in which a message should be distributed. The SNS supports two ways to simulate GeoCasts. A simple but performant model (SimpleAdhocTransmissionModel) \u0026amp; a fairly realistic model ( SophisticatedAdhocTransmissionModel).\nThe simple model assumes a transmission to all entities in the specified area, whereas the delay will be calculated using the configured delay-type and the successful reception will be determined by the uniformly distributed lossProbability. The figure below depicts this behaviour   Simple GeoBroadCast: The RSU is sending to all entities in the destination area. All arrows (transmissions) will have a uniquely calculated delay or possible loss.   The realistic model accounts for possible transmission failures more accurately. The easiest case is that the sender itself is inside of the destination area1 and will start a Flooding Transmission  within this area (see figure below).   GeoBroadCast using Flooding Transmission. Note: the area is not limited to circles.   In case the sending entity is outside of the destination area, a Forwarding Transmission  has to be executed first. This is can also be described as an AnyCast, since the goal of this transmission is to reach any entity inside the destination area. We try to achieve this by building a \u0026ldquo;chain\u0026rdquo; of entities, that will forward the message to the destination are (see figure below).   Forwarding Transmission, by building a \u0026ldquo;chain\u0026rdquo; of vehicles.   The SNS however never uses Forwarding Transmissions  individually, rather they are combined with a Flooding Transmission  , which will simulate a way, that GeaCasts can be implemented in reality. The figure below depicts this behaviour.   Forwarding Transmission followed by a Flooding Transmission to realistically simulate GeoCasts.   Transmission Models As already mentioned in the previous abstracts, the SNS supports different transmission models for different use cases. Depending on the configuration of the SNS and the type of message send, different models will be used. The models are located in the package org.eclipse.mosaic.fed.sns.ambassador.model. This chapter aims to give a detailed inside in the workings of the models.\nSimpleAdhocTransmissionModel This is the most basic of all transmission models and will be your model of choice if you are not interested in completely accurate transmission results but care for performance. This model will approximate GeoCasts using the defined simpleMultihopDelay and simpleMultihopTransmission parameters. For TopoCasts the usual singlehopDelay will be used. This model only checks, whether a potential receiver is inside the destination area and has enabled Adhoc capabilities. If those conditions are met it will simulate the transmission by calculating an actual delay value and saving it into a transmission-result. Such a result holds information of the success of the transmission, the delay-value, the amount of hops, and the number of attempts. Though the amount of hops will always be 1 for this model.\nSophisticatedAdhocTransmissionModel This model offers are more realistic simulation of adhoc transmissions, using an implementation of a greedy-forwarding and flooding algorithm (see here (greedy forwarding)  \u0026amp; here (flooding)  ). For TopoCasts this model behaves very similarly to the SimpleAdhocTransmissionModel, since TopoCasts are always configured with only one hop. For GeoCasts however, this model follows the flowchart above, trying to \u0026ldquo;approach\u0026rdquo; a destination area if it can\u0026rsquo;t be reached directly.\nApproaching (Greedy forwarding) Approaching can be imagined as building a \u0026ldquo;chain\u0026rdquo; of entities to reach an area. However, there is no guarantee, that even if such a chain exists, it will be found. The way that this chain is build follows the subsequent steps:\n Start from the sender and collect all reachable entities. Choose out of all reachable entities the one, that is closest to any node in the destination area. Use the chosen node and repeat the first step. Repeat until either a node inside the destination area is reached, or the TTL (time to live) is exceeded.  By always choosing the node with the shortest distance to the destination area, we omit a lot of possible solutions. Greedy Forwarding isn\u0026rsquo;t optimal, but offers a performant approach for this problem. \u0026ldquo;Face Routing\u0026rdquo;-algorithms will always find a path if one exists, however this hasn\u0026rsquo;t been implemented yet (feel free to contribute :). The figure below shows an example of those shortcomings, the message will be send using the green nodes and won\u0026rsquo;t receive the destination area, even though there is a possible \u0026ldquo;chain\u0026rdquo; using the yellow nodes.\n image/svg+xml       Layer 1 Destination Area Destination Area Destination Area Sender Sender Sender    This figure depicts a case were the Approaching Transmission wouldn\u0026rsquo;t reach the destination area, even though there is a possible way. (The dashed lines represent the communication range)   Flooding The implementation of Flooding is fairly equivalent as described on wikipedia  . Each entity forwards the message to all entities in its communication range. Entities, that already received the message won\u0026rsquo;t receive it again; this is different from many real-life implementations, where messages are send to all reachable entities except the sender. However, since the simulation has total knowledge of all simulated entities, it is easier to overcome a lot of the disadvantages, that flooding faces in real world implementations.\nImplementing your own AdhocTransmissionModel If the implemented models don\u0026rsquo;t suffice your needs you can easily implement your own. Create a class extending AdhocTransmissionModel and implement the abstract methods for sending TopoCasts/GeoCasts. A possible extension could be to allow for multihop TopoCasts, building an actual topology and transmit your messages using that topology. Also, the aforementioned \u0026ldquo;Face-Routing\u0026rdquo; could be of interest. Additionally, the calculation of delays could be made more realistic.\nAccessing SNS-functionality from your applications In order for your scenario to enable the SNS follow the steps here  . An overview of how to configure AdHoc-modules and usage of the API for Routing and Message-Building functions, can be found here  .\n  Or is able to communicate with an entity inside the destination area. \u0026#x21a9;\u0026#xfe0e;\n   ","date":1593471600,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1593471600,"objectID":"848a0c0a1afd14ed7264603bb2725ecf","permalink":"https://www.eclipse.org/mosaic/docs/simulators/network_simulator_sns/","publishdate":"2020-06-30T00:00:00+01:00","relpermalink":"/mosaic/docs/simulators/network_simulator_sns/","section":"docs","summary":"The Simple Network Simulator (SNS) aims to provide simple and fast capabilities for the transmission of V2X-messages using Ad hoc communication. In order to stay performant the simulator makes abstractions in certain places.","tags":null,"title":"Simple Network Simulator (SNS)","type":"docs"},{"authors":null,"categories":null,"content":"The OMNeT++ Federate design is based on amicrosimulation where every participating vehicle respectively node is individually modeled and simulated and all entities are clued together in a scenario with one instance the manages the interaction between them. That means at first the internals of one node are introduced which incorporate mainly the communication stack and a mobilitymodel. Afterwards, especially the scenario management is presented which builds up on the individual nodes and controls themajor part of the simulation. These both aspects are in similar way needed formost mobile communication simulation with OMNeT++ even in an isolated setup. However, specifically for interaction and synchronization with the other simulators in the Eclipse MOSAIC environment, a third pillar is necessary. This scheduler module is very important for the system as it implements the time management and event scheduling according to Eclipse MOSAIC specific concepts.\nNode Internals The main part of the node model consists of the communication stack. The submodules for communication are adopted from the INETMANET framework. Hence, it is primarily important to define the connections between the individual modules. However, there are also modules which needed to be implemented for the dedicated purpose of the coupling within the Eclipse MOSAIC environment. Finally, all modules are linked together to a compound module using the NED language. The following figure depicts the node architecture. It needs to be said that the concept currently supports two different kinds of nodes for Vehicles and RSUs, while V2X-based traffic lights are treated as RSUs. For the first approach these two kinds of nodes have the equal construction in terms of modules. The difference at the moment is that they can be configured with different values for parameters e.g. that Vehicles and RSUs have a different antenna height which is important for Two Ray Ground ReflectionModel. Furthermore, this concept is capable for later extensions e.g. for simulations when RSUs should be equipped with an additional network interface to build the bridge fromAd hoc Domain to the Fixed Infrastructure Domain (i.e. Internet).\n Architecture of one Node   Communication Stack The right part of the block diagram in the figure above depicts the communication stack. It is based on the module Wlan which is a compound module itself and covers the complete IEEE 802.11 network interface card with the MAC and PHY Layer and the Radio Channel. The configuration of different values for standard parameters e.g. the PHY bit rate or size of the contention window of the MAC can be exchanged within the omnetpp.ini-file (which introduces the parameters of the according module ned-files). Please note that the configuration allows different values for each kind of nodes and hence it is possible to configure another propagation model or carrier frequency for Vehicles compared to RSUs. Even if the possibility for such a configuration exists, it should be avoided and common parameters should consistently be configured twice with the same value.\nThe next module in the communication stack is the NetworkLayer. Once again it is a compound module and already a collection of most important protocols. The following protocols from version IPv4 are supported in this layer.\n IP (Internet Protocol) of course as primary protocol of the Network Layer ICMP (Internet ControlMessage Protocol) for information and error messages IGMP (Internet GroupManagement Protocol) for management ofmulticast functionality ARP (Address Resolution Protocol) for mapping of IP Addresses toMAC Addresses  Furthermore, the standalone modules InterfaceTable and RoutingTable are related to the Network Layer. The first one is needed to support multiple Network Interface Cards e.g. for wireless and fixed LAN in one node. It is already included for possible further extensions as previously mentioned, but up to now it has only one entry which is the Network Interface Card for Wlan. The second one is a table for simple Routing. This module is needed for correct instantiation of a node via the FlatNetworkGenerator as explained later in this section.\nThe TransportLayer of the communication stack is made up of TCP for reliable connections and UDP.\nThe modules VSimRTIReliableApp and VSimRTIUnreliableApp of Application Layer are the entry points for application messages for the communication stack for the following reasons. The communication oriented models of INETMANET have their focus more on the framing for communication and less on the real content. That means that content is often modeled with dummy payloads where only the length is of interest. In contrast, V2X applications which are simulated in the Application Simulator  . Rely on the correct transmission of contents. Hence, the modules VSimRTIReliableApp and VSimRTIUnreliableApp are introduced to bridge this gap. They are triggered by the Eclipse MOSAIC ScenarioManager to send new messages to lower layers and forward messages themselves back to the ScenarioManager upon reception. The main tasks are generally acting as an application within the scope of OMNeT++ and encapsulating themessage contents to packets to prepare them for sending. While functionality of an UDP application is fully supported in VSimRTIUnreliableApp, the complete TCP application functionality is restricted in VSimRTIReliableApp. Note that up to now it is not entirely clarified if and how TCP should be supported in V2X use cases for safety and traffic efficiency with their broadcast characteristics, think of different roles of server and client in TCP. When the Eclipse MOSAIC ScenarioManager properties are detailed later in this section, it is also explained how the connection between the Eclipse MOSAIC ScenarioManager and the Eclipse MOSAIC Apps is realized. This connection needs to be established dynamically and is therefore not assigned with a connecting arrow like the fixed connections between the modules of communication stack.\nMobility Model The second important component of the node is the mobility module VSimRTIMobility, which extends the BasicMobility. Unlike other mobility models as RandomWaypoint it does not generate node movements itself and has a straight static character. Node position updates are always triggered by the Eclipse MOSAIC ScenarioManager. Hence,mobility is completely controlled by Eclipse MOSAIC and in turn by the coupled traffic simulator. After successful position update the VSimRTIMobility module informs other modules about this event via the NotificationBoard.\nAdditional Functionality At last, the module NotificationBoard is defined for each node. This module was already mentioned in the model overview of INETMANET. It enables a very efficient way for dynamic communication between the individual modules. There is no direct and static connection needed between the modules, because modules can subscribe dynamically for notification about dedicated events.\nSimulation Setup The setup of the complete simulation is illustrated in the following Figure 3 From the view of OMNeT++, the simulation is a network which has a dynamic topology and is referenced as the simulated network in the omnetpp.ini-file for configuration. The ini-file gives access to all parameters which are offered to be configured by the included simple modules. The parameters are referred to by their hierarchical names with the simulated network as root module. As it is possible to assign already default values for parameters in the modules NED file, not every parameter needs to be configured in the ini-file. The simulation consists of basically three parts.\n Architecture of the whole Simulation Scenario   Simulated Nodes Obviously the major part of the simulation is dedicated to the nodes. They are compound modules either from type Vehicle or RSU and have the properties as described in the previous section. The number of nodes in the simulation can vary over simulation time and is dynamically managed by the Eclipse MOSAIC ScenarioManager.\nCommon Communication Dependent Modules The second part covers the modules which actually count to the communication stack, but are common for all simulated nodes. These modules are the ChannelControl and the FlatNetworkGenerator. The ChannelControl keeps track of all nodes, their positions and Radio Channels. The main task is to determine which nodes are in communication range and which other nodes are within interference distance. The FlatNetworkGenerator is part of the Network Layer. It is used to instantiate a network with a flat topology and assigns the IP addresses to all nodes. Additionally it runs Dijstra’s shortest path algorithm to discover the routes and adds them into the routing tables. It is assumed that the routing tables are of kind of the RoutingTable from the specific NetworkLayer package. This is the reason why every node is equipped with the RoutingTable submodule. This approach works out for the current simulation purposes, but when any Ad hoc Routing protocols will be introduced to the simulation model the FlatNetworkGenerator and the RoutingTable modules are likely be obsolete and would have to be replaced.\nEclipse MOSAIC ScenarioManager The ScenarioManager is an experimental feature that implements a central control instance in simulations with INETMANET framework. It is loaded with a script in XML notation and is used to setup and control simulation experiments. Actually the original ScenarioManager and the new Eclipse MOSAIC ScenarioManager have nearly nothing in common but the fact that both are used as a central management instance to enhance simple configurations to simulate more sophisticated scenarios. The general tasks of the Eclipse MOSAIC ScenarioManager contain the simulation start up with instantiation of common modules as ChannelControl and initialization of the Eclipse MOSAIC EventScheduler (detailed later) and the controlled simulation shut down. But most important beside these are the management of node mobility and management of V2X communication which are triggered by Eclipse MOSAIC during simulation.\nThe Mobility Management is responsible for administration of simulated nodes and their mobility. This includes introducing nodes to simulation, updating node positions and removing nodes from simulation.\nThe node introduction method is triggered by Eclipse MOSAIC with the commands ADD_NODES or ADD_RSU_NODES respectively. It adds the node according to its node id to the managed modules and creates the complete compound module. Important for later message handling is the setup of connections to the dedicated Eclipse MOSAIC App, which is done via so called gates. At the moment, the Eclipse MOSAIC Apps are statically initialized, but the concept is suitable to be extended later when other transport protocols and in turn applications have to be simulated.\nUpon MOVE_NODE command, which contains the affected node id and new position to be updated, the node is moved via the VSimRTIMobility module.\nAt last the REMOVE_NODE command indicates that a node leaves the simulation. On this event, the according node is deleted and unregistered from managed modules.\nThe CommunicationManagement controls the sending and receiving of V2X messages.\nThe SEND_V2X_MESSAGE command initiates the sending process. It contains the sender node id and the transport protocol. Thus the Eclipse MOSAIC ScenarioManager can select the according Eclipse MOSAIC app at the according node.\nWhen a message from another node successfully arrives at the application layer the Eclipse MOSAIC ScenarioManager is notified by the according node. Then, it sets up a RECV_V2X_MESSAGE which is sent back to Eclipse MOSAIC via the Eclipse MOSAIC EventScheduler. This intermediate step is introduced, since the Eclipse MOSAIC EventScheduler is the only instance, which is connected to Eclipse MOSAIC and which knows when it is safe to receive and send interactions.\nSimulator Coupling OMNeT++ is connected to Eclipse MOSAIC according to the concept of high-level-architecture (HLA). That means that the OMNeT++ simulation program itself is encapsulated in the OMNeT++ federate. To enable the coupling according to Eclipse MOSAIC concept, two components needed to be developed. First, the OMNeT++ federate is extended with the customized Eclipse MOSAIC EventScheduler, which can receive and send interactions forMobility and CommunicationManagement. The second component is the OMNeT++ Ambassador that can handle on the one hand the OMNeT++ specific connection and on the other hand the well-defined interface to Eclipse MOSAIC. The emphasis of both components lies in the synchronized exchange of interactions i.e. a time management mechanism must be jointly realized by them. For this purpose the conservative synchronization mechanism is implemented. The following figure gives an overview of the included compenents.\n Overview of Simulator Coupling   Eclipse MOSAIC EventScheduler The Eclipse MOSAIC EventScheduler extends the simple standard scheduler of OMNeT++ to be able to implement the time management for the Conservative Synchronization with Eclipse MOSAIC. It is the only module in OMNeT++ which has access to the event queue or Future Event Set (FES). Since the OMNeT++ simulation is an event driven simulation the scheduler has to fulfill two tasks. The first task is the actual scheduling part which is always invoked by the simulation kernel to schedule the next event. It allows all events from the FES to be processed up to the granted logical time $T$. If there are only events with a later time $T'$ than $T$ left in the FES, it sends the Next Event Request (NER) to the OMNeT++ Ambassador at Eclipse MOSAIC side and blocks the OMNeT++ simulation. Then the second task comes into operation. If necessary, it coordinates the Receive Interaction procedure and merges the external events from Eclipse MOSAIC and hence from other federates to the internal FES. Events with the same time stamp are ordered to the FES according to first come first serve mechanism. Note that the handling of these simultaneous events is generally important to ensure repeatable execution of simulations. The decision about ordering is in control of the federate itself, since the RTI does not sufficiently have the information to do this. After the Receive Interaction step, the RTI completes the time management cycle with the Time Advance Grant for $T'$. At this point the scheduler can set its logical time to $T = T'$ and unblock the further processing.\nAdditionally the Eclipse MOSAIC EventScheduler provides the service for other modules to send interactions back to the OMNeT++ Ambassador, since it is also the one module which is connected to Eclipse MOSAIC. Currently, this is used by the Eclipse MOSAIC ScenarioManager to report the RECEIVE_V2X_MESSAGES.\nEclipse MOSAIC OMNeT++ Federate Development This section provides a description how to set up the OMNeT++ IDE for the Eclipse MOSAIC OMNeT++ Federate Development.\nAt this point it is awaited, that the OMNeT++ Federate  is successfully installed.\nPrepare OMNeT++ IDE   Create an empty directory somewhere inside your home directory. We will call it \u0026lt;omnetpp_workspace\u0026gt; from here on. This directory will be used as a workspace in your OMNeT++ IDE.\n  Open your OMNeT++ IDE by executing omnetpp in your terminal.\n  Select \u0026lt;omnetpp_workspace\u0026gt; as workspace and continue by clicking Launch.\n  Close the \u0026ldquo;Welcome\u0026rdquo; screen.\n  Since your workspace is empty, the OMNeT++ IDE will ask you if you want to install the INET framework and OMNeT++ programming examples.\n OMNeT++ IDE: Install INET   Decide by yourself if you want to do that:\n By clicking OK the INET framework is going to be installed into an inet folder in your \u0026lt;omnetpp_workspace\u0026gt; If you already have INET installed somewhere you can skip the installation and import your existing INET project:  Cancel the dialog. Choose File \u0026gt; Open Projects from File System... In the new window choose the directory of your existing INET installation as Import Source and click Finish      The project inet should now be visible in the Project Explorer of your OMNeT++ IDE.\n  Right-click on free space in the Project Explorer and choose New \u0026gt; OMNeT++ Project...\n OMNeT++ IDE: Create new OMNeT++ Project     In the new window:\n Name the new project federate Uncheck the box before Use default location, click Browse and select:\n\u0026lt;mosaic\u0026gt;/bin/fed/omnetpp/omnetpp_federate_src/src\n OMNeT++ IDE: Create new OMNeT++ Project    Click Next    On the following Initial Contents page select Empty Project and continue by clicking Finish\nYou should now find two projects in the Project Explorer of your OMNeT++ IDE: inet and federate\n  Right-click on the federate project and choose Properties\n Go to Project references and check the box before inet\n Choose project references       That\u0026rsquo;s it! None of the files should now be marked with an error symbol.\n Configure Rebuild Configuration Since the Eclipse MOSAIC OMNeT++ Federate is not a classic OMNeT++ project, it cannot be build regulary with the OMNeT++ IDE by just clicking on the Build button. However, to make the build process easy and intuitive we provide a simple build script and the following desciption how to configure the OMNeT++ IDE to enable building on a single click:\n In the OMNeT++ IDE select Run \u0026gt; External Tools \u0026gt; External Tools Configuration... Double-click in the left column on Program to create a new configuration. Call it rebuild federate In the Main tab:  Under Location choose Browse Workspace... and select federate/rebuild_federate.sh Still in the Main tab under Working Directory choose Browse Workspace... and select federate  OMNeT++ IDE Build Configuration      In the Build tab uncheck the box before Build before launch\n OMNeT++ IDE Build Configuration    Now you can Apply your changes and click on Run. Since you have built the project at least once, you can rebuild it again by clicking here:\n Run rebuild     The following video shows the above described steps:\n  Configure Debug Configuration To debug the Eclipse MOSAIC OMNeT++ Federate during simulation you need to create a Debug Configuration. The following instruction will tell you how to that:\n In your OMNeT++ IDE choose Run \u0026gt; Debug Configurations... In the new window double-click on OMNeT++ Simulation in the left column and name the new created debug configuration federate. In the Executable row check other and type /federate/federate In the Working dir row type /federate In the Ini file(s) row type debug.ini omnetpp.ini At the end of the page click on the More \u0026gt;\u0026gt; link. And make sure all fields in the Advanced area are empty. For Projects to build select Do not build automatically before launch Now Apply your changes and try your configuration by clicking Debug  The following images shows the final debug configuration:\n Final debug configuration    The OMNeT++ Ambassador The OMNeT++ Ambassador is the intermediate component between OMNeT++ and Eclipse MOSAIC. As it implements the interface of an abstract federate ambassador in Eclipse MOSAIC. In the initialization phase the Ambassador applies for the TimeManagement policies time constrained and time regulated at the RTI. Remind that time constrained means that the time advances of the OMNeT++ Federate are dependent on the other simulators in the federation and time regulating means that the OMNeT++ Federate itself can prevent other federates from advancing their time.\nThe OMNeT++ simulation starts initially with an empty event queue and hence it needs to receive an interaction to fill the event queue with the first events to be processed. That means that the typical time management cycle in the Ambassador starts at step two with the Receive Interaction procedure. Note that messages within Eclipse MOSAIC usually effect more than one interaction e.g. a VehicleUpdates interaction contains information for added nodes and moved nodes. These are exchanged with OMNeT++ using a simple byte protocol. After this procedure the third step of time management cycle is processed with the initial Time Advance Grant. This is the point when the OMNeT++ simulation is able to start and the initialization phase is finished. Hence the time management cycle can be executed from first step which is waiting for a new NER until no federate requests further events and the simulation is finished.\nThe Time Representation One important issue for the simulation coupling is the common representation of the logical time at the RTI and the different federates in the federation. Normally, the time is a federate-defined abstract data type. The requirements for such a time are the ability for comparison and addition and most important the possibility of conversion without the loss of precision. Otherwise, deadlocks in the synchronization procedure are guaranteed. On the one hand Eclipse MOSAIC treats times as a 64-bit integer with a resolution of nanoseconds. On the other hand the OMNeT++ simulation time is represented by the type simtime_t which is a typedef to double. It is generally known that conversions from floating point to fixed point are vulnerable to rounding errors. To circumvent this issue the underlying raw 64-bit integer of the simtime_t representation is also made accessible, which works perfect if the scale exponent for time precision was previously initialized to $-9$ (i.e. nanoseconds).\n","date":1557010800,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1557010800,"objectID":"e17d5285bdeec55226cf2b05562bd701","permalink":"https://www.eclipse.org/mosaic/docs/extending_mosaic/omnetpp_details/","publishdate":"2019-05-05T00:00:00+01:00","relpermalink":"/mosaic/docs/extending_mosaic/omnetpp_details/","section":"docs","summary":"The OMNeT++ Federate design is based on amicrosimulation where every participating vehicle respectively node is individually modeled and simulated and all entities are clued together in a scenario with one instance the manages the interaction between them.","tags":null,"title":"OMNeT++ Federate Implementation","type":"docs"},{"authors":null,"categories":null,"content":"MOSAIC has different types of delays implemented for different use cases. This page will give a short introduction into the types and their usages, as well as example configurations, which are used throughout MOSAIC. The implementations can be found in the package org.eclipse.mosaic.lib.model.delay. Note prior to the release of MOSAIC delay values were configured using Milliseconds as unit, this has been refactored to Nanoseconds. Alternatively you can specify delay values using a String with a unit (eg \u0026quot;delay\u0026quot;: \u0026quot;20 ms\u0026quot;).\nDelay Models The Delay class represents an implementation for a specific delay model. The following model implementation exist:\nConstantDelay The ConstantDelay-class is arguably the simplest implementation of Delay. This model is configured with a single field delay, which the generateDelay(...)-method will simply return.\nWhile this delay doesn\u0026rsquo;t provide realistic behaviour in most cases it is optimal for testing purposes as it can easily be retraced.\nConfiguration:\n\u0026quot;delay\u0026quot;: { \u0026quot;type\u0026quot;: \u0026quot;ConstantDelay\u0026quot;, \u0026quot;delay\u0026quot;: \u0026quot;20 ms\u0026quot; }  SimpleRandomDelay The SimpleRandomDelay model allows for the generated delays to be randomly distributed between a minDelay and a maxDelay. Additionally, the steps field is used to limit the amount of different delays, by equally separating the interval into the amount of steps specified. This delay provides a simple and performant way to randomize and thereby more realistically reflect real-world delays.\nFor example, with the configuration below, one of the following delays is randomly chosen: [0.4, 0.9, 1.4, 1.9, 2.4] ms.\nConfiguration:\n\u0026quot;delay\u0026quot;: { \u0026quot;type\u0026quot;: \u0026quot;SimpleRandomDelay\u0026quot;, \u0026quot;steps\u0026quot;: 5, \u0026quot;minDelay\u0026quot;: \u0026quot;0.4 ms\u0026quot;, \u0026quot;maxDelay\u0026quot;: \u0026quot;2.4 ms\u0026quot; }  Gamma Delays MOSAIC provides two types of delays using a Gamma-distribution to sample values, namely GammaRandomDelay and GammaSpeedDelay. The parameters for the used Gamma-distribution have been determined experimentally. The GammaSpeedDelay extends the GammaRandomDelay by a speed penalty. Both delay-types aim to provide more realistic solution, than the previous models, but come with the downside of complexity.\nConfigurations:\n\u0026quot;delay\u0026quot;: { \u0026quot;type\u0026quot;: \u0026quot;GammaRandomDelay\u0026quot;, \u0026quot;minDelay\u0026quot;: \u0026quot;10 ms\u0026quot;, \u0026quot;expDelay\u0026quot;: \u0026quot;30 ms\u0026quot; }  \u0026quot;delay\u0026quot;: { \u0026quot;type\u0026quot;: \u0026quot;GammaSpeedDelay\u0026quot;, \u0026quot;minDelay\u0026quot;: \u0026quot;10 ms\u0026quot;, \u0026quot;expDelay\u0026quot;: \u0026quot;30 ms\u0026quot; }  ","date":1593471600,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1593471600,"objectID":"991360c7135b1da7033c0bd4be1d7e9f","permalink":"https://www.eclipse.org/mosaic/docs/extending_mosaic/delay_models/","publishdate":"2020-06-30T00:00:00+01:00","relpermalink":"/mosaic/docs/extending_mosaic/delay_models/","section":"docs","summary":"MOSAIC has different types of delays implemented for different use cases. This page will give a short introduction into the types and their usages, as well as example configurations, which are used throughout MOSAIC.","tags":null,"title":"Delay Models","type":"docs"},{"authors":null,"categories":null,"content":"The built-in Eclipse MOSAIC Cell Simulator enables the applications to use cellular network communication. The simulation of cellular communication in Eclipse MOSAIC consists of two parts:\n The Cellular Simulator itself and The applications that can communicate over cellular networks in the Application Simulator  These changes are done in a generic way, making the cellular simulator exchangeable. Users interested in a different kind of simulation of cellular communication may use other simulators and develop ambassadors connecting them to Eclipse MOSAIC.\nThe Cellular Simulator in the current state consists of three main modules:\n UplinkModule GeocasterModule DownlinkModule  The Geocaster module simulates a mandatory component for ITS communication. It is inspired by the several architectures from research projects as simTD or CONVERGE to enable ITS use cases over cellular networks. It mainly takes over the task of an addressing and routing component with geographic knowledge to support geo-addressing. However, it also supports regular topological addressing. The Uplink and DownlinkModule are responsible for the transmission simulation. They account for the aspects of transmission delays, packet losses and available data rates. In this context,Uplink and Downlink always refer to the direction towards respectively from the Geocaster. For instance, a transmission from an Internet-based server towards a vehicle would include an Uplink between the server and the Geocaster and a Downlink between the Geocaster and the vehicle. While the Uplink direction only allows point-to-point communication (Unicast), the Downlink supports point-to-point (Unicast) as well as point-to-multipoint (Multicast).\nCellAmbassador folder structure The Eclipse MOSAIC Cell simulator can be configured via three distinct configuration files, which can be found within the scenarios' folder structure:\n└─ \u0026lt;scenario_name\u0026gt; └─ cell ├─ cell_config.json ................. Cell ambassador configuration file ├─ network.json ..................... Network configuration file └─ regions.json ..................... Regions configuration file  The network and regions configuration files are referenced in the cellular ambassador configuration file.\n Read the detailed documentation of the Network and Regions Configuration.\n  Installation This simulator does not need to be installed. It is delivered as part of the Eclipse MOSAIC-installation package.\nConfiguration We provide a cellular configuration file in the example scenarios of Tiergarten and Barnim. Please note that in the default configuration of this scenario the Cellular Simulator is deactivated. To activate the cellular simulator just enable the cell federate in the scenario_config.json:\n\u0026quot;federates\u0026quot;: { ... \u0026quot;cell\u0026quot;: true, ... }  The central configuration for the cellular simulator in the file \u0026lt;scenarioName\u0026gt;/cell/cell_config.json could look like this:\n{ \u0026quot;debugGeocasting\u0026quot;: false, \u0026quot;visualizeRegions\u0026quot;: true, \u0026quot;networkConfigurationFile\u0026quot;: \u0026quot;network.json \u0026quot;, \u0026quot;regionConfigurationFile\u0026quot;: \u0026quot;regions.json \u0026quot; }  The visualizeRegions option from the cell_config.json is used to write a KML-file that visualizes the used cell regions. Google Earth can be used to display it.\n Read the detailed documentations of:\n Cell Network Configuration Cell Region Configuration    The configuration for the global network in the cellular simulator in the file \u0026lt;scenarioName\u0026gt;/cell/network.json could look like this:\n{ \u0026quot;globalNetwork\u0026quot;: { \u0026quot;uplink\u0026quot;: { \u0026quot;delay\u0026quot;: { \u0026quot;type\u0026quot;: \u0026quot;ConstantDelay\u0026quot;, \u0026quot;delay\u0026quot;: \u0026quot;100 ms\u0026quot; }, \u0026quot;transmission\u0026quot;: { \u0026quot;lossProbability\u0026quot;: 0.0, \u0026quot;maxRetries\u0026quot;: 2 }, \u0026quot;capacity\u0026quot;: 28000000 }, \u0026quot;downlink\u0026quot;: { \u0026quot;unicast\u0026quot;: { \u0026quot;delay\u0026quot;: { \u0026quot;type\u0026quot;: \u0026quot;ConstantDelay\u0026quot;, \u0026quot;delay\u0026quot;: \u0026quot;50 ms\u0026quot; }, \u0026quot;transmission\u0026quot;: { \u0026quot;lossProbability\u0026quot;: 0.0, \u0026quot;maxRetries\u0026quot;: 2 } }, \u0026quot;multicast\u0026quot;: { \u0026quot;delay\u0026quot;: { \u0026quot;type\u0026quot;: \u0026quot;ConstantDelay\u0026quot;, \u0026quot;delay\u0026quot;: \u0026quot;100 ms\u0026quot; }, \u0026quot;transmission\u0026quot;: { \u0026quot;lossProbability\u0026quot;: 0.0 }, \u0026quot;usableCapacity\u0026quot;: 0.6 }, \u0026quot;capacity\u0026quot;: 42200000 } } }  The network.json also allows setting the fields defaultDownlinkCapacity and defaultUplinkCapacity, which are used if you don\u0026rsquo;t specify any bitrates in your CellConfigurations inside your applications. These values are set to 100 Gigabit by default, so if you aren\u0026rsquo;t interested in capacity/bandwidth observations you can probably just leave them as is.\nServer configuration MOSAIC supports a type of simulation units, called servers. Traffic Management Centers are a specialised type of server. What differentiates servers from other units is, that they are treated as having no geographical location and instead are located \u0026ldquo;inside the internet.\u0026rdquo;. This concept omits prior shortcoming, where one would have to configure RSU\u0026rsquo;s as servers.\nServers are also configured in the network.json as follows:\n{ \u0026quot;defaultDownlinkCapacity\u0026quot;: \u0026quot;10 Gbps\u0026quot;, \u0026quot;defaultUplinkCapacity\u0026quot;: \u0026quot;10 Gbps\u0026quot;, \u0026quot;globalNetwork\u0026quot;: { [...] }, \u0026quot;servers\u0026quot;: { { \u0026quot;id\u0026quot;: \u0026quot;TestServer\u0026quot;, \u0026quot;uplink\u0026quot;: { \u0026quot;delay\u0026quot;: { \u0026quot;type\u0026quot;: \u0026quot;ConstantDelay\u0026quot;, \u0026quot;delay\u0026quot;: \u0026quot;200 ms\u0026quot; }, \u0026quot;transmission\u0026quot;: { \u0026quot;lossProbability\u0026quot;: 0.5, \u0026quot;maxRetries\u0026quot;: 2 } }, \u0026quot;downlink\u0026quot;: { \u0026quot;unicast\u0026quot;: { \u0026quot;delay\u0026quot;: { \u0026quot;type\u0026quot;: \u0026quot;SimpleRandomDelay\u0026quot;, \u0026quot;steps\u0026quot;: 5, \u0026quot;minDelay\u0026quot;: \u0026quot;100 ms\u0026quot;, \u0026quot;maxDelay\u0026quot;: \u0026quot;200 ms\u0026quot; }, \u0026quot;transmission\u0026quot;: { \u0026quot;lossProbability\u0026quot;: 0.1, \u0026quot;maxRetries\u0026quot;: 2 } } } }, { [...] } } }   Note: The fields defaultDownlinkCapacity, defaultUplinkCapacity are used if you don\u0026rsquo;t define any bitrates for your cell configurations their default values are 100 Gigabit, so you usually don\u0026rsquo;t need to set them.\n Servers get their configuration for the delay and retransmission models from the network.json and the configuration for the capacity-model has to be made from within an application, by activating the CellModule and properly setting the bit rates. This could look as follows:\ngetOs().getCellModule().enable( new CellModuleConfiguration() .maxUlBitrate(10000) .maxDlBitrate(10000) ); // Alternatively using default values from network.json getOs().getCellModule().enable();  For the CellAmbassador to be able to recognize servers, the group-field in the mapping must match the id-field in the network.json, this also allows for multiple servers to utilize the same configuration. A mapping_config.json using the configuration from above could look as follows:\n{ ..., \u0026quot;tmcs\u0026quot;: [ { \u0026quot;group\u0026quot;: \u0026quot;TestServer\u0026quot;, \u0026quot;applications\u0026quot;: [ \u0026quot;TestApplication\u0026quot; ], \u0026quot;inductionLoops\u0026quot;: [ ], \u0026quot;laneAreaDetectors\u0026quot;: [ ] } ], \u0026quot;servers\u0026quot;: [ { \u0026quot;group\u0026quot;: \u0026quot;TestServer\u0026quot;, \u0026quot;applications\u0026quot;: [ \u0026quot;TestApplication\u0026quot; ] } ], ... }   Note that all bandwidths are given in bit per second and all delays in nanoseconds, unless explicitly defined differently. Also, every json configuration goes through a minifier, so comments are allowed in the configuration files. An example would be the comment before the globalNetwork option.\n Delay regions Additionally, the user has the option to define regions with individual delays. This can be used to simulate areas with bad reception, crowded areas etc.\nThe regions should be stored in \u0026lt;scenarioName\u0026gt;/cell/regions.json. An example definition for a single region called Ernst-Reuter-Platz could look like this:\n{ \u0026quot;regions\u0026quot;:[ { \u0026quot;id\u0026quot;: \u0026quot;Ernst-Reuter-Platz\u0026quot;, \u0026quot;area\u0026quot;: { \u0026quot;nw\u0026quot;: { \u0026quot;lon\u0026quot;:13.3249, \u0026quot;lat\u0026quot;:52.5131 }, \u0026quot;se\u0026quot;: { \u0026quot;lon\u0026quot;:13.3273, \u0026quot;lat\u0026quot;:52.5125 } }, \u0026quot;uplink\u0026quot;: { \u0026quot;delay\u0026quot;: { \u0026quot;type\u0026quot;: \u0026quot;SimpleRandomDelay\u0026quot;, \u0026quot;steps\u0026quot;: 4, \u0026quot;minDelay\u0026quot;: \u0026quot;50 ms\u0026quot;, \u0026quot;maxDelay\u0026quot;: \u0026quot;200 ms\u0026quot; }, \u0026quot;transmission\u0026quot;: { \u0026quot;lossProbability\u0026quot;: 0.8, \u0026quot;maxRetries\u0026quot;: 2 }, \u0026quot;capacity\u0026quot;: 28000000 }, \u0026quot;downlink\u0026quot;: { \u0026quot;unicast\u0026quot;: { \u0026quot;delay\u0026quot;: { \u0026quot;type\u0026quot;: \u0026quot;SimpleRandomDelay\u0026quot;, \u0026quot;steps\u0026quot;: 3, \u0026quot;minDelay\u0026quot;: \u0026quot;100 ms\u0026quot;, \u0026quot;maxDelay\u0026quot;: \u0026quot;200 ms\u0026quot; }, \u0026quot;transmission\u0026quot;: { \u0026quot;maxRetries\u0026quot;: 2 } }, \u0026quot;multicast\u0026quot;: { \u0026quot;delay\u0026quot;: { \u0026quot;type\u0026quot;: \u0026quot;SimpleRandomDelay\u0026quot;, \u0026quot;steps\u0026quot;: 3, \u0026quot;minDelay\u0026quot;: \u0026quot;120 ms\u0026quot;, \u0026quot;maxDelay\u0026quot;: \u0026quot;220 ms\u0026quot; }, \u0026quot;transmission\u0026quot;: { \u0026quot;lossProbability\u0026quot;: 0.8 }, \u0026quot;usableCapacity\u0026quot;: 0.6 }, \u0026quot;capacity\u0026quot;: 42200000 } } ] }  Note that nw represents the upper-left (north-west) point of the rectangle and se the lower-right (southeast). For further information about the possible options, please refer to the Eclipse MOSAIC API documentation.\nThe actual configuration of the uplink and the downlink modules for each region exhibits the identical format as configuration of the globalNetwork in the network.json.\nWhen no regions are found, or if a node (a vehicle) is not within a specified region, the globalNetwork defined in the network.json-File will be used as the delay model.\nTransmission simulation One of the most important feature of the cellular simulator is an estimation of the delay experienced through the transport over the cellular network.\nThe cellular simulator offers various modes to estimate the delay of the transmissions. The type of estimation is specified with by delayType for the uplink and downlink for each region. You may also refer to the Delay-Chapter  .\n delay.type = ’ConstantDelay’: The message is transmitted with the latency being exactly equal to delay. delay.type = ’SimpleRandomDelay’: The latency can assume different (randomly generated and uniformly distributed) values between minDelay and maxDelay. The number of different values is determined by steps. delay.type = ’GammaRandomDelay’: A gamma distribution is used to estimate the latency, with $ \\alpha $ = 2 and $ \\beta $= 2. The minimal delay minDelay is added to the result. The curve is fitted so that the maximum likelihood for the delay is exactly equal to expDelay. delay.type = ’GammaSpeedDelay’: This mode closely resembles the GammaRandomDelay. Additionally, a penalty for the velocity with which the node is moving is calculated. This penalty is then added to the original delay. The GammaRandomDelay and the GammaSpeedDelay are derived from a measurement campaign during a research project at the DCAITI.  The two different modes for the downlink are unicast and multicast which are configured separately. Multicast aims to simulate the features of Multimedia Broadcast Multicast Service (MBMS). The main difference in terms of the transmission for unicast and multicast is the handling of undeliverable messages. For unicast, the options lossProbability and maxRetries are used. Pr is short for packet retransmit and denotes the probability for a failed delivery and a subsequent retransmit. The maximum number of retries for the retransmission is configured through the maxRetries-option. The probability of a successful retransmit is recalculated on every try.\nIn case of multicast the lossProbability is used as packet loss rate. The value is factored into the delay calculation. In contrast to the unicast, just one transmission attempt is made for multicast.\nOperation Beside the transmission simulation, the Addressing and Routing is the other important aspect of the Cellular Simulator. This task is enabled by the Geocaster.\nThe Geocaster evaluates the message headers for cellular messages, which are created by the communicating applications in the Application Simulator.\nIt supports the following addressing and casting schemes.\n[CellTopocast](/docs/develop_applications/communication#cellular-topocast) is the normal unicast, where the Geocaster simply resolves the single receiver via theIPResolver. Hence, the CellTopocast directly routes the message further. Currently, Topocast doesn\u0026rsquo;t allow broadcast or anycast addresses, but any transmission protocols (tcp, udp).\n[CellGeoUnicast](/docs/develop_applications/communication#cellular-geocast) addresses every node in the destination area individually. In this way it takes a geographic address and results in a loop to generate multiple unicasts.\n[CellGeoBroadcast](/docs/develop_applications/communication#cellular-geobroadcast), which is basically MBMS, uses one broadcast to all nodes in the destined regions.The MBMS uses the different transmission mode of multicast in the downlink. CellGeoUnicast as well as CellGeoBroadcast require broadcast, but don’t allow tcp (as ack for broadcasts is denied).\n","date":1557010800,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1557010800,"objectID":"9a45880dc681c4e5ebf695dc5a761ad6","permalink":"https://www.eclipse.org/mosaic/docs/simulators/network_simulator_cell/","publishdate":"2019-05-05T00:00:00+01:00","relpermalink":"/mosaic/docs/simulators/network_simulator_cell/","section":"docs","summary":"The built-in Eclipse MOSAIC Cell Simulator enables the applications to use cellular network communication. The simulation of cellular communication in Eclipse MOSAIC consists of two parts:\n The Cellular Simulator itself and The applications that can communicate over cellular networks in the Application Simulator  These changes are done in a generic way, making the cellular simulator exchangeable.","tags":null,"title":"Network Simulator Cell","type":"docs"},{"authors":null,"categories":null,"content":"This ambassador can be configured with a configuration file. The specific path is mosaic/scenarios/\u0026lt;scenarioName\u0026gt;/environment/environment_config.json\n└─ \u0026lt;scenario_name\u0026gt; └─ environment └─ environment_config.json ..................... Environment ambassador configuration file  Installation This simulator does not need to be installed. It is delivered as part of the Eclipse MOSAIC-installation package.\nConfiguration  Read the detailed documentation of the Environment Configuration.\n  The root node of the configuration is a list of environment events. Each event require the type of the event, a rectangle area, a strength and the time window. The following example shows the configuration of an \u0026ldquo;Obstacle\u0026rdquo; event which is valid in the designated area (Rectangle) during the simulation time between 0 to 2000 seconds:\n{ \u0026quot;events\u0026quot; : [ { \u0026quot;type\u0026quot;: { \u0026quot;sensorType\u0026quot;: \u0026quot;OBSTACLE\u0026quot;, \u0026quot;value\u0026quot;: 1 }, \u0026quot;location\u0026quot;: { \u0026quot;area\u0026quot;: { \u0026quot;type\u0026quot;: \u0026quot;Rectangle\u0026quot;, \u0026quot;a\u0026quot;: { \u0026quot;latitude\u0026quot;: 52.53654, \u0026quot;longitude\u0026quot;: 13.42116 }, \u0026quot;b\u0026quot;: { \u0026quot;latitude\u0026quot;: 52.53435, \u0026quot;longitude\u0026quot;: 13.42366 } } }, \u0026quot;time\u0026quot;: { \u0026quot;start\u0026quot;: \u0026quot;0 s\u0026quot;, \u0026quot;end\u0026quot;: \u0026quot;2000 s\u0026quot; } } ] }  ","date":1557010800,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1557010800,"objectID":"e2e8c6da6205aac6b2834ce5bed20d3d","permalink":"https://www.eclipse.org/mosaic/docs/simulators/environment_simulator/","publishdate":"2019-05-05T00:00:00+01:00","relpermalink":"/mosaic/docs/simulators/environment_simulator/","section":"docs","summary":"This ambassador can be configured with a configuration file. The specific path is mosaic/scenarios/\u0026lt;scenarioName\u0026gt;/environment/environment_config.json\n└─ \u0026lt;scenario_name\u0026gt; └─ environment └─ environment_config.json ..................... Environment ambassador configuration file  Installation This simulator does not need to be installed.","tags":null,"title":"Environment Simulator","type":"docs"},{"authors":null,"categories":null,"content":"  The Battery Simulator is part of MOSAIC Extended.\nFor further information on licenses, feel free to contact us via mosaic@fokus.fraunhofer.de.\n  The MOSAIC Battery Simulator is used to simulate electric vehicles. It takes environment, vehicle characteristics and the battery itself into account. The main feature of the battery ambassador is that it can utilize dynamic class loading to use a battery model provided by the user, depending on the given needs. This also holds true for the environment model and the vehicle model. However, simple models for vehicles, environment and the battery are provided and will be briefly explained in the following sections.\nInstallation This simulator does not need to be installed. It is delivered as part of the MOSAIC Extended installation package.\nConfiguration This ambassador can be configured with a configuration file. The specific path is \u0026lt;scenarioName\u0026gt;/battery/battery_config.json\n└─ \u0026lt;scenario_name\u0026gt; └─ battery └─ battery_config.json ................. Battery ambassador configuration file  Vehicle model The vehicle model holds the general properties of a vehicle. Examples would be the weight of the vehicle and the voltage at which the electric engine operates. However, as with the other models, the provided class for the vehicle model direct affects what can be configured here. If other properties are needed for the vehicle, this is the right place to put them. To implement an own vehicle, the class AVehicleModel has to be extended.\nBattery model The battery model defines the battery used by the vehicle itself. Useful properties could be the number of cells and their capacity. As with the vehicle, this class can be freely defined and use configuration values placed in the batteryModelConfig-area. To implement an own battery model, the class ABatteryModel needs to be extended.\nEnvironment model Normally environmental factors like rolling resistance of the given underground or air drag go into this section. At the current state, just a minimal environment model is bundled with the battery ambassador, mainly to show what is possible. To implement a custom environmentmodel, AEnvironmentModel has to be extended.\nSample configuration { \u0026quot;vehicleModelClass\u0026quot;: \u0026quot;com.dcaiti.mosaic.fed.battery.sim.models.vehicle.ElectricSmart\u0026quot;, \u0026quot;vehicleModelConfig\u0026quot;: { \u0026quot;Mass\u0026quot;: 1060, \u0026quot;ReferenceArea\u0026quot;: 1.95, \u0026quot;DragCoefficient\u0026quot;: 0.375, \u0026quot;TankToWheelEfficiency\u0026quot;: 0.7, \u0026quot;EletricMotorOperatingVoltage\u0026quot;: 350, \u0026quot;ConsumerOperatingVoltage\u0026quot;: 12 }, \u0026quot;batteryModelClass\u0026quot;: \u0026quot;com.dcaiti.mosaic.fed.battery.sim.models.battery.VerySimpleBatteryModel\u0026quot;, \u0026quot;batteryModelConfig\u0026quot;: { \u0026quot;NumberOfCells\u0026quot;: 93, \u0026quot;CellVoltage\u0026quot;: 4.3, \u0026quot;CellCapacityInAh\u0026quot;: 50, \u0026quot;eff_Summer\u0026quot;: 0.8448, \u0026quot;RechargingType\u0026quot;: 2, \u0026quot;MinSOC\u0026quot;: 0.30, \u0026quot;MaxSOC\u0026quot;: 0.70 }, \u0026quot;environmentModelClass\u0026quot;: \u0026quot;com.dcaiti.mosaic.fed.battery.sim.models.environment.DefaultEnvironment\u0026quot;, \u0026quot;environmentModelConfig\u0026quot;: { \u0026quot;Gravity\u0026quot;: 9.81, \u0026quot;FluidDensity\u0026quot;: 1.293, \u0026quot;RollingResistanceCoefficient\u0026quot;: 0.01 }, \u0026quot;consumers\u0026quot;: [ { \u0026quot;Radio\u0026quot;: 10 }, { \u0026quot;HeadLight\u0026quot;: 100 } ] }  This listing shows how the vehicle, environment and battery model classes for the bundled models are configured. Additionally, an arbitrary number of consumers can be configured that draw additional power from the battery. In this case, headlights and a radio are pre-defined.\n","date":1557010800,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1557010800,"objectID":"564b92ca6ad0f78206e0f1291d3a1002","permalink":"https://www.eclipse.org/mosaic/docs/simulators/battery_simulator/","publishdate":"2019-05-05T00:00:00+01:00","relpermalink":"/mosaic/docs/simulators/battery_simulator/","section":"docs","summary":"The Battery Simulator is part of MOSAIC Extended.\nFor further information on licenses, feel free to contact us via mosaic@fokus.fraunhofer.de.\n  The MOSAIC Battery Simulator is used to simulate electric vehicles.","tags":null,"title":"Battery Simulator","type":"docs"},{"authors":null,"categories":null,"content":"  The VMS Simulator is part of MOSAIC Extended.\nFor further information on licenses, feel free to contact us via mosaic@fokus.fraunhofer.de.\n  The VMS Simulator extends simulations with variable message signs (VMS), which could by dynamically controlled. A VMS can be placed anywhere along a road and has, amongst others, the following properties:\n Type for different traffic sign semantics, Road and lane(s) it corresponds to, Visibility as a value telling how well a sign is visible for road users  The concept of a flexible sign type allows testing future traffic signs which are not existent at the moment and also common VMS types like:\n Speed limit signs Lane assignment signs (assigns a list of allowed vehicle types to a lane - e.g. Busses, Taxis or even Automated Vehicles)    example of speed and lane assigment in highway scenario   Any properties of a VMS, beside its position and type, can be changed during the simulation.\nIn each simulation step the VMS Simulator informs vehicles about any VMS that is inside their sight distance. How vehicles react on VMS can be modeled with the Application Simulator.\n","date":-62135596800,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":-62135596800,"objectID":"334d08c502b7cd358f164be5e98897bb","permalink":"https://www.eclipse.org/mosaic/docs/simulators/vms_simulator/","publishdate":"0001-01-01T00:00:00Z","relpermalink":"/mosaic/docs/simulators/vms_simulator/","section":"docs","summary":"The VMS Simulator is part of MOSAIC Extended.\nFor further information on licenses, feel free to contact us via mosaic@fokus.fraunhofer.de.\n  The VMS Simulator extends simulations with variable message signs (VMS), which could by dynamically controlled.","tags":null,"title":"Variable Message Signs Simulator","type":"docs"},{"authors":null,"categories":null,"content":"Remote-Operated Driving is the bridge technology from human towards fully automated driving. In situations outside the driving domain of a highly-automated vehicle, e.g. if data is missing or the autonomous function is unsure to make a certain decision, remote-operation is the key. Also, in other use-cases, remote-operated driving is a helpful technique, e.g. for driving electric car-sharing vehicles to their charging stations, or maneuvering vehicles remotely through a parking garage.\nIn all those use-cases, a human operator would \u0026ldquo;steer\u0026rdquo; the vehicle remotely. All sensor information would be sent over the 5G network to the operator who can then decide on the action or trajectory the vehicle should follow. The information the operator receives could be any sensor data from the vehicle, such as camera data, LiDAR data, or already compiled information like detected objects and free space. With Mobile Edge Computing and sensor fusion, the information could be enriched by other vehicles or stationary sensors.\nVirtual Testing with MOSAIC helps to dive deeper into this topic. This study bases on LiDAR data for presentation of the operator view, which allows selecting different viewing angles as well as sensor fusion of different perspectives from other vehicles for a holistic environment model. The final result can be seen in the video below.\n   Eclipse MOSAIC has been used to couple the vehicle simulator PHABMACS with the MOSAIC Application simulator, in which a custom application has been deployed providing the operator view. The vehicle simulator PHABMACS is responsible for vehicle dynamics and sensor data, in this case LiDAR data. The message exchange of LiDAR as well as vehicle control data has been simulated by integrating the MOSAIC Cell simulator. In this way, we could analyze the influence of communication properties, e.g. latencies and different connection qualities such as low capacities or packet losses, on the application. For the hybrid test setup with virtual world and real application for the human operators, the whole simulation has to run in real time, which is possible with Eclipse MOSAIC (see parameter --realtime-brake 1).\n","date":1614297600,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1614297600,"objectID":"9e76b2321af77849906fdb06464177a3","permalink":"https://www.eclipse.org/mosaic/post/remote-operated-driving/","publishdate":"2021-02-26T00:00:00Z","relpermalink":"/mosaic/post/remote-operated-driving/","section":"post","summary":"Remote-Operated Driving is the bridge technology from human towards fully automated driving. In situations outside the driving domain of a highly-automated vehicle, e.g. if data is missing or the autonomous function is unsure to make a certain decision, remote-operation is the key.","tags":null,"title":"Testing Remote-Operated Driving virtually with Eclipse MOSAIC","type":"post"},{"authors":null,"categories":null,"content":"The simulative investigation of communication-based Traffic Management solutions requires combining models from different domains. Eclipse MOSAIC suits very well for this purpose as it couples multiple simulators to model vehicle movement pattern, infrastructure sensors, (variable) traffic signs, as well as different communication links (ITS-G5, 4G/5G) between vehicles and backends, and the application logic in entities like vehicles and a Traffic Management Center.\nIn a recent study, we analyzed future traffic estimation and control algorithms towards their use on highways with special focus on mixed traffic of conventional vehicles, connected vehicles, and autonomous vehicles. Connected vehicles share telematic information with a Traffic Management Center (TMC) which can then estimate the traffic state and initiate control mechanisms to improve traffic efficiency either via variable message signs as part of the infrastructure, or via V2X communication directly addressing connected vehicles in order to share speed and lane change advices with the vehicles on the road (e.g. via ETSI IVI message). In a further step, dynamic lane assignments have been established, which dedicate lanes to autonomous vehicles only to enable efficient platooning maneuvers. The individual highlights of Eclipse MOSAIC for simulating such a traffic management system are visualized in the video.\n With Eclipse MOSAIC this system has been modelled and simulated with all its various aspects in order to analyze efficiency improvements of such estimation and control algorithms. As traffic simulator, we employed  Eclipse SUMO  , which already provides a basic model for variable speed signs. However, the preferred MOSAIC VMS Simulator  realizes a more flexible concept with the dynamic control of the VMS during simulation runtime, including arbitrary sign semantics additional to speed and featuring a visibility range. The interplay of information from infrastructure elements as well as communicated information has been modelled in detail with applications covering realistic behavior of human drivers and autonomous vehicles. Additionally, real estimation and control algorithms from external suppliers have been integrated into the simulation to provide a software-in-the-loop environment. The  MOSAIC Mapping   allowed for a comprehensive configuration of the different application components to the simulated entities (variously equipped vehicles, RSUs and a TMC cloud server).\nThe final result was a complex simulation scenario for Eclipse MOSAIC, including a calibrated traffic model, various application and behavior models for automated, connected and conventional vehicles, different communication links via ITS-G5 and cellular communication, infrastructure models for sensors and variable message signs, and a new evaluation component in order to gain statistics out of a simulation.\n   Requirement SUMO   MOSAIC Application   MOSAIC Cell   MOSAIC SNS   MOSAIC VMS   MOSAIC Output       Simulate Vehicle Traffic on Highways X        Measure Traffic Properties (Flow, Density) X        Control Traffic dynamically via VMS (X) X   X    Exchange V2X Messages via ITS-G5 and 4G/5G   X X     Include Vehicle Functions which react on IVIM  X       Model Traffic Management Center Facilities  X       Integrate real TMC algorithms in Simulation  X       Include Roadside Units with custom Functionality  X       Generate aggregated Statistics from the Simulation      X   Generated Detailed Simulation Logs (X)     X    The Simulation Setup The traffic model in this scenario has been created using real toll-data for the highway AP7 in northern Spain, provided by the Spanish toll road management ( Abertis Infraestructuras, S.A.  ). Based on this data, traffic has been generated in Eclipse SUMO and calibrated in a way, that the simulated traffic resembles the original toll data as close as possible. This procedure has been done for the complete highway AP7 and resulted in more than 500.000 vehicles per day in the simulation. However, it would not make real sense to analyze a whole highway stretch, as the control algorithms under test apply very local changes. Therefore, we decided to extract a reduced traffic scenario from the calibrated one by measuring the vehicle movements within a smaller area only. Based on those measurements we were able to create a realistic traffic model on a stretch of 25 kilometers length near Girona.\n The test site modelled in Eclipse MOSAIC   For modelling the infrastructure, the highway has been divided into so-called segments. Each segment, roughly 500m in length, contains spot sensors at the entry of each segment to measure traffic flow, lane area detectors which model cameras to measure traffic density, and Variable Message Signs (VMS) displaying speed limits and lane assignments. Modelling VMS was achieved by the new simulator MOSAIC VMS, which let vehicles \u0026ldquo;see\u0026rdquo; oncoming traffic signs showing speed limits or lane assignments. An additional behavior model for vehicles implemented in the MOSAIC Application Simulator could react on those instructions accordingly.\nThe segmentation of the highway was very important for the traffic estimation and control algorithms which have been integrated into the scenario. Those algorithms, provided by the Technical University of Crete  , can estimate the traffic volume on highways using traditional sensors, but also by receiving CAM messages of connected vehicles. Based on the traffic estimation, additional algorithms can control the traffic by setting speed limits on VMS, or by sending V2X messages (e.g. ETSI IVI messages) with speed recommendations or lane change advices to individual vehicles. The control algorithms were written in C++ and have already been used in real traffic management centers. For this study, we integrated them into the MOSAIC Application  Simulator using the Java Native Interface (JNI).\n Integration of Traffic Control Algorithms into MOSAIC Application using JNI   The estimation algorithms rely on information from vehicles and control algorithms are able to send back advices. Therefore, communication links are required to exchange V2X messages. To achieve this, two separate communications links have been modelled by integrating the  MOSAIC Simple Network Simulator   for ITS-G5 communication, and the  MOSAIC Cell Simulator   for cellular communication (e.g. 5G or LTE-V2X). In the former case, vehicles exchanged message with Road Side Units along the road, which then forwarded the information to the Traffic Management Center (TMC). In the latter case, vehicles were directly connected to the TMC.\nFinally, application models for connected and automated vehicles have been integrated by using the  MOSAIC Application Simulator  . With the help of these applications vehicles could react on advices sent by the TMC. Depending on the SAE level of the vehicle in the simulation, the vehicles would execute a certain advice immediately after some safety checks (fully automated vehicle) or with a certain delay (connected vehicle with a human driver reacting on a lane-change advice).\nEvaluations In a first study, we took a closer look onto the main traffic flow control (MTFC) in general. This algorithm measures the traffic volume on the highway and adjusts the speed limits shown on VMS based on the current flow and density. In many cases, traffic collapses near on-ramps when traffic flow on the highway is already high and additional vehicles are entering, resulting in a capacity drop on the highway and thereby congestion further upstream. To avoid this from happening, the controller reduces the average speed of the main flow resulting in more capacity available at the bottleneck. This effect could be shown in MOSAIC with the setup described above as well, as shown in the Figure below. Here you can see, that the congestion which arises at the bottleneck near segment 30 can be reduced by activating the controller.\n Speed over time on the highway. Left no control enabled, right control algorithm active.   In the previous case, the controller adjusted the speed limit shown on VMS along the highway. Those VMS were placed virtually every 500m along the highway, which would be very expensive to implement on real highways. Therefore, we reduced the number of VMS placed along the highway and tested the algorithm again. VMS were now placed at strategic positions rather than equidistant. To be more precisely, five VMS were placed between two consecutive on-ramps, having one VMS to control the speed near the bottleneck, three safety VMS which reduce the speed stepwise further upstream, and one VMS after the on-ramp to release the vehicles from the control area. As a result, we could spare over 60% of the VMS placed along the specific highway stretch without seeing much difference in the results.\n In the left case, VMS are placed every 500m. In the right case only few VMS at strategic locations.   In addition to controlling the traffic by setting VMS, vehicles do receive speed limits or speed advices via communication using IVI messages. Those messages contain control decisions for each segment and are spread to the vehicles using ITS-G5 adhoc communication. For this purpose, the simulation scenario is modelled in a way, that a road side unit is placed at each segment entry. Equipped vehicles adjust their speeds and therefore control the traffic flow as a whole, as other vehicles (e.g. their followers) are forced to adjust their speeds as well. With this fact given, we did another experiment in which we eliminated all VMS completely and sent speed limits only via V2X communication to equipped vehicles. This, on one hand, already works with rather low penetration rates of 15 percent equipped vehicles, as shown in the Figure below. Furthermore, the higher the penetration rate is, the better the controller works. For high penetration rates, this technique even surpasses the classic approach via VMS slightly, as connected vehicles can react and controlled more precisely.\n In the left case traffic is controlled via VMS. In the right case, only V2X messages are utilized.   Conclusion We modelled complex traffic scenarios including road infrastructures (sensors, dynamic traffic signs, road side units), individual driving behavior for different SAE levels. Furthermore, we integrated real algorithms for traffic estimation and control into MOSAIC Application enabling software-in-the-loop tests. By creating and calibrating a highway scenario using real toll data, we could test different traffic control techniques which showed that traffic flow on highways could be improved, even with novel approaches which do not rely on classic infrastructure such as road sensors and Variable Message Signs, but almost solely on V2X communication.\n   This work was part of the INFRAMIX  project. INFRAMIX has received funding from the European Union\u0026rsquo;s Horizon 2020 research and innovation programme under grant agreement no 723016.\n","date":1610928000,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1610928000,"objectID":"5e0e434280e8ddf9f66096928c2151a1","permalink":"https://www.eclipse.org/mosaic/post/traffic-control/","publishdate":"2021-01-18T00:00:00Z","relpermalink":"/mosaic/post/traffic-control/","section":"post","summary":"The simulative investigation of communication-based Traffic Management solutions requires combining models from different domains. Eclipse MOSAIC suits very well for this purpose as it couples multiple simulators to model vehicle movement pattern, infrastructure sensors, (variable) traffic signs, as well as different communication links (ITS-G5, 4G/5G) between vehicles and backends, and the application logic in entities like vehicles and a Traffic Management Center.","tags":null,"title":"Studying Traffic Control Algorithms in MOSAIC","type":"post"},{"authors":null,"categories":null,"content":"The initial contribution is accomplished! With the autumn version, the committer team from Fraunhofer FOKUS and DCAITI is proud to release Eclipse MOSAIC 20.0 to the open source community. With the runtime infrastructure, core libraries and various implementations of simulators or couplings to existing ones, Eclipse MOSAIC includes the essential feature collection for simulation and virtual testing of connected and automated mobility solutions.\nRelease Date 2020-10-19\nChangelog [M+] Moved main code to new public repository github-com/eclipse-mosaic [M+] Changed license to EPL 2.0 [M+] Revised and refactored all public code. [M+] Significantly improved and extended the documentation, including new tutorials [M-] Replaced dependencies which are incompatible with EPL. [M+] Major overhaul of configuration files, e.g. * vsimrti/vsimrti_config.xml -\u0026gt; scenario_config.json * etc/defaults.xml -\u0026gt; etc/runtime.json [A+] Mapping configuration has been extended with new features (e.g. typeDistributions, parameter variations). [A+] New API for traffic light applications [C+] SNS supports most important Geo-Routing features for ad-hoc multihop communication [T+] Now supports SUMO 1.7.0  Changelog (Features and Bugfixes) Legend:\n[M] Eclipse MOSAIC\n[A] Application simulator\n[B] Battery simulator\n[C] Communication simulator\n[E] Environment simulator\n[N] Navigation component\n[S] Scenario-convert\n[T] Traffic simulator\n[+/-] new Feature/Bugfix\n","date":1603065600,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1603065600,"objectID":"cc4c07b071bbda44d7b128dbd1954e1e","permalink":"https://www.eclipse.org/mosaic/post/release-20-0/","publishdate":"2020-10-19T00:00:00Z","relpermalink":"/mosaic/post/release-20-0/","section":"post","summary":"The initial contribution is accomplished! With the autumn version, the committer team from Fraunhofer FOKUS and DCAITI is proud to release Eclipse MOSAIC 20.0 to the open source community. With the runtime infrastructure, core libraries and various implementations of simulators or couplings to existing ones, Eclipse MOSAIC includes the essential feature collection for simulation and virtual testing of connected and automated mobility solutions.","tags":null,"title":"First release of Eclipse MOSAIC","type":"post"},{"authors":[],"categories":[],"content":"On the occasion of EclipseCon 2020, Fraunhofer FOKUS launches its simulation environment Eclipse MOSAIC. This solution is based on VSimRTI (Vehicle-2-X Simulation Runtime Infrastructure), which has been developed over the last 12 years in close cooperation with the DCAITI of the TU Berlin and has already been used by more than 600 partners to test mobility services and traffic scenarios. Eclipse MOSAIC is now partially available as open-source.\nWhether dynamic lane assignment or traffic light phase assistant, new mobility services are designed to increase safety, efficiency, comfort, and facilitate environmentally friendly transport. The Eclipse MOSAIC simulation environment allows to explore how this can be achieved, before the services are tested in field trials on the road. Eclipse MOSAIC can also be used for testing driver assistance systems and to optimize the entire traffic.\nFlexible coupling of simulators Eclipse MOSAIC integrates, depending on the simulation scenario, different aspects like individual building blocks into a holistic system, e.g., traffic congestion, battery charging of electric cars, or communication between other road users and a central cloud. The level of detail for individual aspects is variable: from a rough mobility scenario for an entire city to detailed individual driving maneuvers.\nThe open-source version of Eclipse MOSAIC already includes several simulators, e.g., Eclipse SUMO for traffic and OMNeT++ and ns-3 for communication. Further simulators can be coupled, e.g., Fraunhofer FOKUS offers the simulator PHABMACS for the realistic modeling of autonomous vehicles.\nIn addition to the simulator coupling, Eclipse MOSAIC manages the following tasks:\n Federation: Individual simulators are interchangeable within a scenario. Interaction: Information from one simulator is also taken into account by others. Time: All simulators run synchronously.  Additionally, Eclipse MOSAIC offers several tools for evaluation and visualization of the results, which are also included in the open-source package.\nIn the recently completed EU project INFRAMIX, Eclipse MOSAIC was used to test scenarios for the future road that allow mixed traffic between conventional and automated vehicles.\nFraunhofer FOKUS has been a strategic development member of the Eclipse Foundation since May of this year and works in close cooperation with the partners of the working groups OpenMobility and openADx (Open Source for Autonomous Driving).\nFurther information about Eclipse MOSAIC: https://www.eclipse.org/mosaic https://github.com/eclipse/mosaic\nFurther information about INFRAMIX: https://www.fokus.fraunhofer.de/de/fokus/news/inframix-projekt_2020_08\nFurther information about EclipseCon: https://www.eclipsecon.org/2020\n","date":1602806400,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1602806400,"objectID":"945968ed12d4d56ceff36a8ffcc80747","permalink":"https://www.eclipse.org/mosaic/post/eclipse-mosaic/","publishdate":"2020-10-16T00:00:00Z","relpermalink":"/mosaic/post/eclipse-mosaic/","section":"post","summary":"On the occasion of EclipseCon 2020, Fraunhofer FOKUS launches its simulation environment Eclipse MOSAIC. This solution is based on VSimRTI (Vehicle-2-X Simulation Runtime Infrastructure), which has been developed over the last 12 years in close cooperation with the DCAITI of the TU Berlin and has already been used by more than 600 partners to test mobility services and traffic scenarios. Eclipse MOSAIC is now partially available as open-source.","tags":[],"title":"Testing mobility scenarios with the Open-Source simulation environment Eclipse MOSAIC","type":"post"},{"authors":null,"categories":null,"content":"","date":1546300800,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1546300800,"objectID":"8576ec274c98b3831668a172fa632d80","permalink":"https://www.eclipse.org/mosaic/about/","publishdate":"2019-01-01T00:00:00Z","relpermalink":"/mosaic/about/","section":"","summary":"Hello!","tags":null,"title":"About","type":"widget_page"},{"authors":null,"categories":null,"content":"","date":1546300800,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1546300800,"objectID":"7cb4b52984a9d47af29166100a552aba","permalink":"https://www.eclipse.org/mosaic/get_in_contact/","publishdate":"2019-01-01T00:00:00Z","relpermalink":"/mosaic/get_in_contact/","section":"","summary":"Eclipse MOSAIC.","tags":null,"title":"Contact","type":"widget_page"},{"authors":null,"categories":null,"content":"","date":1546300800,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1546300800,"objectID":"614f103684a170a5d2fd1d1f92949420","permalink":"https://www.eclipse.org/mosaic/contribution/","publishdate":"2019-01-01T00:00:00Z","relpermalink":"/mosaic/contribution/","section":"","summary":"List of publications and thesis related to Eclipse MOSAIC.","tags":null,"title":"Contribution to Eclipse MOSAIC","type":"widget_page"},{"authors":null,"categories":null,"content":"","date":1546300800,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1546300800,"objectID":"bf47fe1505bc48f51aef798d7a4d34a6","permalink":"https://www.eclipse.org/mosaic/download/","publishdate":"2019-01-01T00:00:00Z","relpermalink":"/mosaic/download/","section":"","summary":"List of links to download the latest releases and other components.","tags":null,"title":"Download","type":"widget_page"},{"authors":null,"categories":null,"content":"","date":1546300800,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1546300800,"objectID":"7bb3ac9163e73505cd320646a459de77","permalink":"https://www.eclipse.org/mosaic/community/","publishdate":"2019-01-01T00:00:00Z","relpermalink":"/mosaic/community/","section":"","summary":"Eclipse MOSAIC Community","tags":null,"title":"Eclipse MOSAIC Community","type":"widget_page"},{"authors":null,"categories":null,"content":"","date":1546300800,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1546300800,"objectID":"9eb50f9088083bebcb7e4cf99e22b9ed","permalink":"https://www.eclipse.org/mosaic/news/","publishdate":"2019-01-01T00:00:00Z","relpermalink":"/mosaic/news/","section":"","summary":"News","tags":null,"title":"News","type":"widget_page"},{"authors":null,"categories":null,"content":"","date":1546300800,"expirydate":-62135596800,"kind":"page","lang":"en","lastmod":1546300800,"objectID":"23d1e75f872528fc12f5f2b142375ff7","permalink":"https://www.eclipse.org/mosaic/publications/","publishdate":"2019-01-01T00:00:00Z","relpermalink":"/mosaic/publications/","section":"","summary":"List of publications and thesis related to Eclipse MOSAIC.","tags":null,"title":"Publications","type":"widget_page"}]