blob: fc3071a1bd66dbfc258ffbaf7e731ac2f426c3db [file] [log] [blame]
<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>Eclipse MOSAIC – A Multi-Domain and Multi-Scale Simulation Framework for Connected and Automated Mobility</title>
<link>https://staging.eclipse.org/mosaic/</link>
<atom:link href="https://staging.eclipse.org/mosaic/index.xml" rel="self" type="application/rss+xml" />
<description>Eclipse MOSAIC – A Multi-Domain and Multi-Scale Simulation Framework for Connected and Automated Mobility</description>
<generator>Source Themes Academic (https://sourcethemes.com/academic/)</generator><language>en-us</language><lastBuildDate>Wed, 10 Mar 2021 00:00:00 +0000</lastBuildDate>
<image>
<url>https://staging.eclipse.org/mosaic/images/logo.svg</url>
<title>Eclipse MOSAIC – A Multi-Domain and Multi-Scale Simulation Framework for Connected and Automated Mobility</title>
<link>https://staging.eclipse.org/mosaic/</link>
</image>
<item>
<title>Communication in Applications</title>
<link>https://staging.eclipse.org/mosaic/docs/develop_applications/communication/</link>
<pubDate>Sun, 05 May 2019 00:00:00 +0100</pubDate>
<guid>https://staging.eclipse.org/mosaic/docs/develop_applications/communication/</guid>
<description>&lt;p&gt;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 (&lt;a href=&#34;https://staging.eclipse.org/mosaic/mosaic/docs/simulators/network_simulator_omnetpp&#34; title=&#34;&#34;&gt;&lt;/a&gt;,
&lt;a href=&#34;https://staging.eclipse.org/mosaic/mosaic/docs/simulators/network_simulator_ns3/&#34;&gt;
ns-3
&lt;/a&gt;
) or one of the built-in communication simulators
&lt;a href=&#34;https://staging.eclipse.org/mosaic/mosaic/docs/simulators/network_simulator_sns/&#34;&gt;
SNS
&lt;/a&gt;
or
&lt;a href=&#34;https://staging.eclipse.org/mosaic/mosaic/docs/simulators/network_simulator_cell/&#34;&gt;
Eclipse MOSAIC Cell
&lt;/a&gt;
. Furthermore, for a better understanding it is important to consider the network types of Eclipse MOSAIC in more
detail.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Cellular Communication&lt;/li&gt;
&lt;li&gt;Ad-hoc Communication&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Generally, the following modes are available based on network:&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Cellular Communication&lt;/strong&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Geobroadcast&lt;/li&gt;
&lt;li&gt;Geocast&lt;/li&gt;
&lt;li&gt;Topocast&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;strong&gt;Ad-hoc Communication&lt;/strong&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Geobroadcast&lt;/li&gt;
&lt;li&gt;Geocast&lt;/li&gt;
&lt;li&gt;Topobroadcast&lt;/li&gt;
&lt;li&gt;Topocast&lt;/li&gt;
&lt;/ul&gt;
&lt;hr&gt;
&lt;h2 id=&#34;cellular-communication&#34;&gt;Cellular Communication&lt;/h2&gt;
&lt;p&gt;The cellular network is known from wireless mobile communication and the principle is to divide the entire geographic
area into several smaller parts called &lt;strong&gt;&amp;ldquo;cells&amp;rdquo;&lt;/strong&gt;. Each cell has a fixed-location transceiver with a coverage ratio.&lt;/p&gt;
&lt;p&gt;Eclipse 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.&lt;/p&gt;
&lt;h3 id=&#34;cellular-geobroadcast&#34;&gt;Cellular Geobroadcast&lt;/h3&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;The following figure illustrates a vehicle &lt;em&gt;&lt;strong&gt;veh_2&lt;/strong&gt;&lt;/em&gt; which is communicating with the other
vehicles(&lt;em&gt;&lt;strong&gt;veh_1&lt;/strong&gt;&lt;/em&gt;, &lt;em&gt;&lt;strong&gt;veh_3&lt;/strong&gt;&lt;/em&gt;) within a radius &lt;strong&gt;R&lt;/strong&gt;.&lt;/p&gt;
&lt;figure id=&#34;figure-illustration-of-geobroadcast-in-a-spezific-circular-area&#34;&gt;
&lt;a data-fancybox=&#34;&#34; href=&#34;../images/tiergarten-geobroadcast-circular-area.png&#34; data-caption=&#34;Illustration of Geobroadcast in a spezific circular area&#34;&gt;
&lt;img src=&#34;../images/tiergarten-geobroadcast-circular-area.png&#34; alt=&#34;&#34; &gt;
&lt;/a&gt;
&lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
Illustration of Geobroadcast in a spezific circular area
&lt;/figcaption&gt;
&lt;/figure&gt;
&lt;p&gt;A circular communication area can be defined with the &lt;code&gt;geoBroadCast(GeoCircle geoCircle)&lt;/code&gt; from an Eclipse MOSAIC application,
as shown below:&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;GeoCircle transmissionArea = new GeoCircle(GeoPoint.latlon(52.5, 13.2), 3000);
MessageRouting routing = getOs().getCellModule().createMessageRouting().geoBroadCast(transmissionArea);
getOs().getCellModule().sendV2XMessage(new MyV2XMessage(routing));
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;A rectangular destination area can be defined similarly:&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;GeoPoint 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));
&lt;/code&gt;&lt;/pre&gt;
&lt;h3 id=&#34;cellular-geocast&#34;&gt;Cellular Geocast&lt;/h3&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Assume, the &lt;em&gt;&lt;strong&gt;veh_1&lt;/strong&gt;&lt;/em&gt; has a message which is addressed to &lt;em&gt;&lt;strong&gt;veh_2&lt;/strong&gt;&lt;/em&gt;. In order to send the message, &lt;em&gt;&lt;strong&gt;veh_1&lt;/strong&gt;&lt;/em&gt; first
examines whether the vehicle with ID &lt;em&gt;&lt;strong&gt;veh_2&lt;/strong&gt;&lt;/em&gt; is located within the transmission area. If this is the case, the
message will be transmitted. In figure below is this situation illustrated.&lt;/p&gt;
&lt;figure id=&#34;figure-cellular-geocast-to-address-a-receiver-within-a-defined-area&#34;&gt;
&lt;a data-fancybox=&#34;&#34; href=&#34;../images/tiergarten-geocast-circular-area.png&#34; data-caption=&#34;Cellular Geocast to address a receiver within a defined area&#34;&gt;
&lt;img src=&#34;../images/tiergarten-geocast-circular-area.png&#34; alt=&#34;&#34; &gt;
&lt;/a&gt;
&lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
Cellular Geocast to address a receiver within a defined area
&lt;/figcaption&gt;
&lt;/figure&gt;
&lt;p&gt;The following methods are provided for the configuring the transmission area (Circle or Rectangle) and the addressing to
the receiver(hostname or ip address).&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;code&gt;geoCast(GeoCircle geoCircle, String receiverName) &lt;/code&gt;&lt;/li&gt;
&lt;li&gt;&lt;code&gt;geoCast(GeoRectangle geoRectangle, String receiverName)&lt;/code&gt;&lt;/li&gt;
&lt;li&gt;&lt;code&gt;geoCast(GeoCircle geoCircle, byte[] ipAddress)&lt;/code&gt;&lt;/li&gt;
&lt;li&gt;&lt;code&gt;geoCast(GeoRectangle geoRectangle, byte[] ipAddress)&lt;/code&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;GeoCircle transmissionArea = new GeoCircle( GeoPoint.latlon(52.5, 13.2), 3000);
String receiverName = &amp;quot;veh_0&amp;quot;;
MessageRouting routing = getOs().getCellModule().createMessageRouting().geoCast(transmissionArea, receiverName);
getOs().getCellModule().sendV2XMessage(new MyV2XMessage(routing));
&lt;/code&gt;&lt;/pre&gt;
&lt;h3 id=&#34;cellular-topocast&#34;&gt;Cellular Topocast&lt;/h3&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;The next figure illustrates how the &lt;em&gt;&lt;strong&gt;veh_0&lt;/strong&gt;&lt;/em&gt; is communicating with &lt;em&gt;&lt;strong&gt;veh_1&lt;/strong&gt;&lt;/em&gt; in Topocast mode.&lt;/p&gt;
&lt;figure id=&#34;figure-topocast-mode-for-direct-addressing-without-geographical-constraints&#34;&gt;
&lt;a data-fancybox=&#34;&#34; href=&#34;../images/tiergarten-cellular-topocast.png&#34; data-caption=&#34;Topocast mode for direct addressing without geographical constraints&#34;&gt;
&lt;img src=&#34;../images/tiergarten-cellular-topocast.png&#34; alt=&#34;&#34; &gt;
&lt;/a&gt;
&lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
Topocast mode for direct addressing without geographical constraints
&lt;/figcaption&gt;
&lt;/figure&gt;
&lt;p&gt;The code example below shows how we can configure the requirements of the communication in Topocast mode.&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;String receiverName = &amp;quot;veh_0&amp;quot;;
MessageRouting routing = getOs().getCellModule().createMessageRouting().topoCast(receiverName);
getOs().getCellModule().sendV2XMessage(new MyV2XMessage(routing));
&lt;/code&gt;&lt;/pre&gt;
&lt;h3 id=&#34;setting-protocol-types&#34;&gt;Setting Protocol types&lt;/h3&gt;
&lt;p&gt;By default, all cell messages use UDP, however you can set the protocol using the &lt;code&gt;protocol(...)&lt;/code&gt; method of the &lt;code&gt;MessageRoutingBuilder&lt;/code&gt;:&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;String receiverName = &amp;quot;veh_0&amp;quot;;
MessageRouting routing = getOs().getCellModule().createMessageRouting()
.protocol(Protocoltype.TCP)
.topoCast(receiverName);
getOs().getCellModule().sendV2XMessage(new MyV2XMessage(routing));
&lt;/code&gt;&lt;/pre&gt;
&lt;hr&gt;
&lt;h2 id=&#34;ad-hoc-communication&#34;&gt;Ad-hoc Communication&lt;/h2&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Eclipse 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.&lt;/p&gt;
&lt;p&gt;The following table shows the possible channels on the 5.9 GHz band used for V2X communication.&lt;/p&gt;
&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Channel Number&lt;/th&gt;
&lt;th&gt;0&lt;/th&gt;
&lt;th&gt;1&lt;/th&gt;
&lt;th&gt;2&lt;/th&gt;
&lt;th&gt;3&lt;/th&gt;
&lt;th&gt;4&lt;/th&gt;
&lt;th&gt;5&lt;/th&gt;
&lt;th&gt;6&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;Channel Name&lt;/td&gt;
&lt;td&gt;SCH1&lt;/td&gt;
&lt;td&gt;SCH2&lt;/td&gt;
&lt;td&gt;SCH3&lt;/td&gt;
&lt;td&gt;CCH&lt;/td&gt;
&lt;td&gt;SCH4&lt;/td&gt;
&lt;td&gt;SCH5&lt;/td&gt;
&lt;td&gt;SCH6&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Frequency Band&lt;/td&gt;
&lt;td&gt;5.86&lt;/td&gt;
&lt;td&gt;5.87&lt;/td&gt;
&lt;td&gt;5.88&lt;/td&gt;
&lt;td&gt;5.89&lt;/td&gt;
&lt;td&gt;5.9&lt;/td&gt;
&lt;td&gt;5.91&lt;/td&gt;
&lt;td&gt;5.92&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;h3 id=&#34;configuring-adhoc-capabilities&#34;&gt;Configuring AdHoc Capabilities&lt;/h3&gt;
&lt;p&gt;The first step to enable your application to use Ad hoc capabilities, is to make sure it extends the &lt;code&gt;AbstractSimulationUnit&lt;/code&gt;-class
or one of its child-classes (e.g. &lt;code&gt;VehicleUnit&lt;/code&gt;, &lt;code&gt;ChargingStationUnit&lt;/code&gt;) found in package
&lt;code&gt;org.eclipse.mosaic.fed.application.ambassador.simulation&lt;/code&gt;. Additionally, if you want your application to act upon
the reception or transmission of messages, make sure it implements the interface &lt;code&gt;CommunicationApplication&lt;/code&gt;.&lt;br&gt;
Once 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 &lt;code&gt;.power(...)[mW]&lt;/code&gt; it is also possible to configure
a &lt;code&gt;.distance(...)[m]&lt;/code&gt;.&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;// Example of AdHocConfiguration (see TiergartenVehicle.java)
@Override
public void onStartup() {
getOs().getAdHocModule().enable(new AdHocModuleConfiguration()
.addRadio()
.channel(AdHocChannel.CCH)
.power(50)
.create());
}
&lt;/code&gt;&lt;/pre&gt;
&lt;h3 id=&#34;ad-hoc-topobroadcast&#34;&gt;Ad-hoc Topobroadcast&lt;/h3&gt;
&lt;p&gt;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:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Singlehop&lt;/li&gt;
&lt;li&gt;Multihop&lt;/li&gt;
&lt;/ul&gt;
&lt;h4 id=&#34;singlehop-approach-in-topobroadcast&#34;&gt;Singlehop approach in Topobroadcast&lt;/h4&gt;
&lt;p&gt;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 &lt;strong&gt;hop = 1&lt;/strong&gt;. Moreover, Eclipse MOSAIC allows to use the default method
&lt;code&gt;topoBroadCast()&lt;/code&gt; 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 &lt;code&gt;topoBroadCast(AdHocChannel)&lt;/code&gt; in order to
specify the Ad-hoc channel.&lt;/p&gt;
&lt;p&gt;Below are some configuration examples of the default addressing method &lt;code&gt;topoBroadCast()&lt;/code&gt; and non-default addressing
method &lt;code&gt;topoBroadCast(AdHocChannel)&lt;/code&gt;.&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;MessageRouting routing = getOs().getAdHocModule().createMessageRouting().topoBroadCast();
getOs().getAdHocModule().sendV2XMessage(new MyV2XMessage(routing));
&lt;/code&gt;&lt;/pre&gt;
&lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;AdHocChannel commonChannel = AdHocChannel.SCH1;
MessageRouting routing = getOs().getAdHocModule().createMessageRouting().topoBroadCast(commonChannel);
getOs().getAdHocModule().sendV2XMessage(new MyV2XMessage(routing));
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;The following figure shows a simplified model based on the Singlehop principle. The &lt;em&gt;veh_1&lt;/em&gt; sends messages to all
simulation entites(&lt;em&gt;&lt;strong&gt;RSU&lt;/strong&gt;&lt;/em&gt;, &lt;em&gt;&lt;strong&gt;veh_2&lt;/strong&gt;&lt;/em&gt;) that are using the same Ad-hoc channel. After transmission, the message can
no longer be forwarded by the receiver.&lt;/p&gt;
&lt;figure id=&#34;figure-overview-singlehop-with-specified-ad-hoc-channel&#34;&gt;
&lt;a data-fancybox=&#34;&#34; href=&#34;../images/tiergarten-adhoc-topobroadcast-singlehop.png&#34; data-caption=&#34;Overview Singlehop with specified Ad-hoc channel&#34;&gt;
&lt;img src=&#34;../images/tiergarten-adhoc-topobroadcast-singlehop.png&#34; alt=&#34;&#34; &gt;
&lt;/a&gt;
&lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
Overview Singlehop with specified Ad-hoc channel
&lt;/figcaption&gt;
&lt;/figure&gt;
&lt;h4 id=&#34;multihop-approach-in-topobroadcast&#34;&gt;Multihop approach in Topobroadcast&lt;/h4&gt;
&lt;p&gt;In Multihop, the lifespan (amount of hops) of a message can be specified, allowing larger communication distances.&lt;/p&gt;
&lt;p&gt;The following figure shows a Multihop example with a data package D (M, h = 2) from the vehicle &lt;em&gt;veh_0&lt;/em&gt; 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.&lt;/p&gt;
&lt;figure id=&#34;figure-overview-multihop-principle&#34;&gt;
&lt;a data-fancybox=&#34;&#34; href=&#34;../images/tiergarten-adhoc-topobroadcast.png&#34; data-caption=&#34;Overview Multihop principle&#34;&gt;
&lt;img src=&#34;../images/tiergarten-adhoc-topobroadcast.png&#34; alt=&#34;&#34; &gt;
&lt;/a&gt;
&lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
Overview Multihop principle
&lt;/figcaption&gt;
&lt;/figure&gt;
&lt;p&gt;The next code snippet shows a configuration example with an Ad-hoc channel and a message lifespan &lt;strong&gt;hops = 2&lt;/strong&gt;.&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;AdHocChannel commonChannel = AdHocChannel.SCH1;
int hops = 2;
MessageRouting routing = getOs().getAdHocModule().createMessageRouting().topoBroadCast(commonChannel, hops);
getOs().getAdHocModule().sendV2XMessage(new MyV2XMessage(routing));
&lt;/code&gt;&lt;/pre&gt;
&lt;div class=&#34;alert alert-note&#34;&gt;
&lt;div&gt;
&lt;p&gt;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 (
&lt;a href=&#34;https://staging.eclipse.org/mosaic/mosaic/docs/simulators/network_simulator_omnetpp/&#34;&gt;
OMNeT++
&lt;/a&gt;
,
&lt;a href=&#34;https://staging.eclipse.org/mosaic/mosaic/docs/simulators/network_simulator_ns3/&#34;&gt;
ns-3
&lt;/a&gt;
). But the built in communication simulator
&lt;a href=&#34;https://staging.eclipse.org/mosaic/mosaic/docs/simulators/network_simulator_sns/&#34;&gt;
SNS
&lt;/a&gt;
includes a simple routing protocol &amp;ldquo;Flooding&amp;rdquo;.&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;h3 id=&#34;ad-hoc-topocast&#34;&gt;Ad-hoc Topocast&lt;/h3&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;final 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));
&lt;/code&gt;&lt;/pre&gt;
&lt;h3 id=&#34;ad-hoc-geobroadcast&#34;&gt;Ad-hoc Geobroadcast&lt;/h3&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;As example in the following illustration, The vehicles &lt;em&gt;&lt;strong&gt;veh_0&lt;/strong&gt;&lt;/em&gt;, &lt;em&gt;&lt;strong&gt;veh_2&lt;/strong&gt;&lt;/em&gt;, &lt;em&gt;&lt;strong&gt;veh_3&lt;/strong&gt;&lt;/em&gt; and the &lt;em&gt;&lt;strong&gt;RSU&lt;/strong&gt;&lt;/em&gt; are
Ad-hoc equipped and there is no vehicle in the communication range of &lt;em&gt;&lt;strong&gt;RSU&lt;/strong&gt;&lt;/em&gt;, therefore a hop is not possible to next
vehicle &lt;em&gt;&lt;strong&gt;veh_0&lt;/strong&gt;&lt;/em&gt;. But the vehicles &lt;em&gt;&lt;strong&gt;veh_2&lt;/strong&gt;&lt;/em&gt; and &lt;em&gt;&lt;strong&gt;veh_3&lt;/strong&gt;&lt;/em&gt; are able to communicate with each other.&lt;/p&gt;
&lt;figure id=&#34;figure-principle-of-ad-hoc-geobroadcast-mode&#34;&gt;
&lt;a data-fancybox=&#34;&#34; href=&#34;../images/tiergarten-adhoc-network.png&#34; data-caption=&#34;Principle of Ad-hoc Geobroadcast mode&#34;&gt;
&lt;img src=&#34;../images/tiergarten-adhoc-network.png&#34; alt=&#34;&#34; &gt;
&lt;/a&gt;
&lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
Principle of Ad-hoc Geobroadcast mode
&lt;/figcaption&gt;
&lt;/figure&gt;
&lt;p&gt;With the methods&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;code&gt;geoBroadCast(GeoCircle geoCircle)&lt;/code&gt;&lt;/li&gt;
&lt;li&gt;&lt;code&gt;geoBroadCast(GeoRectangle geoRectangle)&lt;/code&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;of the Eclipse MOSAIC class &lt;code&gt;AdHocMessageRoutingBuilder&lt;/code&gt; ,we are able, to configure the required area as a circle or a
rectangle.&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;GeoPoint 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));
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Analogous to the examples above, we can also configure the transmission area as a rectangle.&lt;/p&gt;
&lt;p&gt;The next code snippet illustrates a possible configuration with a rectangular transmission area and a specified Ad-hoc
channel.&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;GeoPoint 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));
&lt;/code&gt;&lt;/pre&gt;
&lt;h3 id=&#34;ad-hoc-geocast&#34;&gt;Ad-hoc Geocast&lt;/h3&gt;
&lt;p&gt;The class AdHocMessageRoutingBuilder only has one method for Geocasting mode,
&lt;code&gt;geoCast(DestinationAddress destinationAddress, AdHocChannel adHocChannel)&lt;/code&gt;. Communication is possible if the
IP-address of receiver is known and both (receiver and transmitter) are on the same Ad-hoc channel.&lt;/p&gt;
&lt;div class=&#34;alert alert-note&#34;&gt;
&lt;div&gt;
&lt;p&gt;In this context the name Geocast is misleading, because a geological condition is not necessary.&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;p&gt;As you can see in the next picture, the RSU uses the Ad-hoc channel &lt;em&gt;SCH1&lt;/em&gt; and several vehicles use different
Ad-hoc channels. Assuming the RSU tries to send a message to &lt;em&gt;veh_1&lt;/em&gt; and has knowledge about the IP-Address of &lt;em&gt;veh_1&lt;/em&gt;,
if the vehicle &lt;em&gt;veh_1&lt;/em&gt; also uses the same channel &lt;em&gt;SCH1&lt;/em&gt;, the transmission will be completed successfully.&lt;/p&gt;
&lt;figure id=&#34;figure-ad-hoc-geocast-communication-between-entities-using-the-same-channel&#34;&gt;
&lt;a data-fancybox=&#34;&#34; href=&#34;../images/tiergarten-geocast-adHoc.png&#34; data-caption=&#34;Ad-hoc Geocast communication between entities using the same channel&#34;&gt;
&lt;img src=&#34;../images/tiergarten-geocast-adHoc.png&#34; alt=&#34;&#34; &gt;
&lt;/a&gt;
&lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
Ad-hoc Geocast communication between entities using the same channel
&lt;/figcaption&gt;
&lt;/figure&gt;
&lt;p&gt;Below you can see a possible configuration.&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;final 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));
&lt;/code&gt;&lt;/pre&gt;
&lt;h2 id=&#34;cam---implementation&#34;&gt;CAM - Implementation&lt;/h2&gt;
&lt;p&gt;A Cooperative Awareness Messages (CAM) consists of four parts:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Header with generic information&lt;/li&gt;
&lt;li&gt;MessageBody&lt;/li&gt;
&lt;li&gt;ServiceList&lt;/li&gt;
&lt;li&gt;TaggedValue list&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;h3 id=&#34;user-defined-tagged-values&#34;&gt;User defined tagged values&lt;/h3&gt;
&lt;p&gt;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 &lt;code&gt;beforeGetAndResetUserTaggedValue()&lt;/code&gt; from the &lt;code&gt;CommunicationApplication&lt;/code&gt; interface. If a CAM is about to be sent, the custom data can be set using the &lt;code&gt;getOs().setUserTaggedValue(byte[])&lt;/code&gt; method. The receiver can simple access the data by accessing the field directly from the received CAM message:&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt; byte[] value = cam.getUserTaggedValue ();
if (value != null) {
// read user tagged value}
}
&lt;/code&gt;&lt;/pre&gt;
&lt;h3 id=&#34;timing-requirements&#34;&gt;Timing Requirements&lt;/h3&gt;
&lt;p&gt;CAMs are generated by the CAM Management and passed to lower layers when any of following rules apply:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;maximum time interval between CAM generations: $1s$;&lt;/li&gt;
&lt;li&gt;minimum time interval between CAM generations: $0.1s$;&lt;/li&gt;
&lt;li&gt;generate CAM when absolute difference between current heading (towards North) and last CAM heading &amp;gt; $4 deg$;&lt;/li&gt;
&lt;li&gt;generate CAM when distance between current position and last CAM position &amp;gt; $5m$&lt;/li&gt;
&lt;li&gt;generate CAM when absolute difference between current speed and last CAM speed &amp;gt; $1ms$;&lt;/li&gt;
&lt;li&gt;These rules are checked latest every $100ms$;&lt;/li&gt;
&lt;/ul&gt;
</description>
</item>
<item>
<title>Event Scheduling</title>
<link>https://staging.eclipse.org/mosaic/docs/develop_applications/event_scheduler/</link>
<pubDate>Sun, 11 Aug 2019 00:00:00 +0000</pubDate>
<guid>https://staging.eclipse.org/mosaic/docs/develop_applications/event_scheduler/</guid>
<description>&lt;p&gt;The different modules of the
&lt;a href=&#34;https://staging.eclipse.org/mosaic/mosaic/docs/simulators/application_simulator/#eclipse-mosaic-application-simulator&#34;&gt;
Application Simulator
&lt;/a&gt;
communicate over events that are triggered at a specific simulation time. The following classes and interfaces model theses events.&lt;/p&gt;
&lt;h3 id=&#34;event&#34;&gt;Event&lt;/h3&gt;
&lt;p&gt;The class &lt;code&gt;Event&lt;/code&gt; 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.&lt;/p&gt;
&lt;h4 id=&#34;attributes-of-event&#34;&gt;Attributes of Event&lt;/h4&gt;
&lt;p&gt;The class Event contains the following attributes:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;code&gt;long time&lt;/code&gt;: defines the time when the execution of the event is triggered.&lt;/li&gt;
&lt;li&gt;&lt;code&gt;long nice&lt;/code&gt;: defines the priority of the event. When multiple events are scheduled for the sametime, the events are ordered in ascending order.&lt;/li&gt;
&lt;li&gt;&lt;code&gt;List&amp;lt;EventProcessor&amp;gt; processors&lt;/code&gt;: is a list of components that shall process the event.&lt;/li&gt;
&lt;li&gt;&lt;code&gt;Object resource&lt;/code&gt;: is an object that contains additional information designated for the processor of the event. The resource can be any object.&lt;/li&gt;
&lt;/ul&gt;
&lt;h4 id=&#34;methods-of-event&#34;&gt;Methods of Event&lt;/h4&gt;
&lt;ul&gt;
&lt;li&gt;&lt;code&gt;Event()&lt;/code&gt;: 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.&lt;/li&gt;
&lt;li&gt;&lt;code&gt;Event newTime(long time)&lt;/code&gt;: allows the creation of a new event with a new execution time based&lt;/li&gt;
&lt;li&gt;&lt;code&gt;String getResourceSimpleClassName()&lt;/code&gt;: returns the class name of the resource as String.&lt;/li&gt;
&lt;li&gt;&lt;code&gt;int compareTo(Event event)&lt;/code&gt;: implements the standardized Java interface
&lt;a href=&#34;https://docs.oracle.com/javase/8/docs/api/java/lang/Comparable.html&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;
Comparable
&lt;/a&gt;
. Toorder the events, first the time of the event is evaluated. In case the times are equal, the priority of the events is compared.&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id=&#34;interface-eventmanager&#34;&gt;Interface EventManager&lt;/h3&gt;
&lt;p&gt;The interface &lt;code&gt;EventManager&lt;/code&gt; defines the method &lt;code&gt;void addEvent(Event event)&lt;/code&gt; that needs to be implemented to add an event to the execution.&lt;/p&gt;
&lt;h3 id=&#34;interface-eventscheduler&#34;&gt;Interface EventScheduler&lt;/h3&gt;
&lt;p&gt;The interface &lt;code&gt;EventScheduler&lt;/code&gt; extends the interface &lt;code&gt;EventManager&lt;/code&gt; and is used for classes that trigger events.&lt;/p&gt;
&lt;h4 id=&#34;methods-of-eventscheduler&#34;&gt;Methods of EventScheduler&lt;/h4&gt;
&lt;ul&gt;
&lt;li&gt;&lt;code&gt;boolean isEmpty()&lt;/code&gt;: returns true if the scheduler contains no elements, otherwise it returns false.&lt;/li&gt;
&lt;li&gt;&lt;code&gt;long getNextEventTime()&lt;/code&gt;: returns the time of the next event.&lt;/li&gt;
&lt;li&gt;&lt;code&gt;long getScheduledTime()&lt;/code&gt;: returns the time when the last event has been executed.&lt;/li&gt;
&lt;li&gt;&lt;code&gt;List&amp;lt;Event&amp;gt; scheduleEvents(long time)&lt;/code&gt;: returns a list of objects that are scheduled for a
certain simulation time.&lt;/li&gt;
&lt;li&gt;&lt;code&gt;Set&amp;lt;Event&amp;gt; getAllEvents()&lt;/code&gt;: returns a set of all events that are considered by the scheduler.&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id=&#34;eventschedulerimpl&#34;&gt;EventSchedulerImpl&lt;/h3&gt;
&lt;p&gt;The class &lt;code&gt;EventSchedulerImpl&lt;/code&gt; is an implementation of the interface &lt;code&gt;EventScheduler&lt;/code&gt;.&lt;/p&gt;
&lt;h3 id=&#34;interface-eventprocessor&#34;&gt;Interface EventProcessor&lt;/h3&gt;
&lt;p&gt;The interface &lt;code&gt;EventProcessor&lt;/code&gt; defines how the execution module gets the events. The execution module
therefore has to implement the following methods:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;code&gt;void processEvent(Event event)&lt;/code&gt;: The module processes the event.&lt;/li&gt;
&lt;li&gt;&lt;code&gt;boolean canProcessEvent()&lt;/code&gt;: returns true when the module is currently able to process new
events, otherwise it returns false.&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id=&#34;interceptedevent&#34;&gt;InterceptedEvent&lt;/h3&gt;
&lt;h3 id=&#34;class-eventinterceptor&#34;&gt;Class EventInterceptor&lt;/h3&gt;
&lt;p&gt;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 &lt;code&gt;EventInterceptor&lt;/code&gt; is used to construct objects of the type &lt;code&gt;InterceptedEvent&lt;/code&gt;.
In the constructor it is possible to specify an EventManager that manages the intercepted events. Moreover, objects of the type &lt;code&gt;EventProcessor&lt;/code&gt; can be specified that shall process the intercepted events.&lt;/p&gt;
&lt;h3 id=&#34;class-interceptedevent&#34;&gt;Class InterceptedEvent&lt;/h3&gt;
&lt;p&gt;The class &lt;code&gt;InterceptedEvents&lt;/code&gt; extends the class Event. It is used to provide type safe allocations of
events that shall be intercepted.&lt;/p&gt;
</description>
</item>
<item>
<title>Scenario Database</title>
<link>https://staging.eclipse.org/mosaic/docs/develop_applications/road_traffic/</link>
<pubDate>Tue, 06 Aug 2019 00:00:00 +0000</pubDate>
<guid>https://staging.eclipse.org/mosaic/docs/develop_applications/road_traffic/</guid>
<description>&lt;p&gt;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
&lt;a href=&#34;https://staging.eclipse.org/mosaic/mosaic/docs/simulators/application_simulator/&#34;&gt;
Application Simulator
&lt;/a&gt;
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 &lt;code&gt;application&lt;/code&gt; folder of the scenario. This database consists of the following tables:&lt;/p&gt;
&lt;h3 id=&#34;database-tables&#34;&gt;Database tables&lt;/h3&gt;
&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th style=&#34;text-align:left&#34;&gt;Database Name&lt;/th&gt;
&lt;th style=&#34;text-align:left&#34;&gt;Description&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Node&lt;/code&gt;&lt;/td&gt;
&lt;td style=&#34;text-align:left&#34;&gt;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 &lt;a href=&#34;http://wiki.openstreetmap.org/wiki/Node&#34; target=&#34;_blank&#34;&gt;http://wiki.openstreetmap.org/wiki/Node&lt;/a&gt;)&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Way&lt;/code&gt;&lt;/td&gt;
&lt;td style=&#34;text-align:left&#34;&gt;Provides various properties for each way of the road network.(refer to &lt;a href=&#34;http://wiki.openstreetmap.org/wiki/Way&#34; target=&#34;_blank&#34;&gt;http://wiki.openstreetmap.org/wiki/Way&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;WayConsistsOf&lt;/code&gt;&lt;/td&gt;
&lt;td style=&#34;text-align:left&#34;&gt;Provides a list of nodes for each way of the road network.&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Connection&lt;/code&gt;&lt;/td&gt;
&lt;td style=&#34;text-align:left&#34;&gt;Contains a list of all connections of the road network including the way it originally is part of. Each connection describes an &lt;em&gt;directed&lt;/em&gt; edge between two junctions in the road network.&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;ConnectionConsistsOf&lt;/code&gt;&lt;/td&gt;
&lt;td style=&#34;text-align:left&#34;&gt;Provides a list of nodes each connection consists of.&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Restriction&lt;/code&gt;&lt;/td&gt;
&lt;td style=&#34;text-align:left&#34;&gt;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.&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;TrafficSignals&lt;/code&gt;&lt;/td&gt;
&lt;td style=&#34;text-align:left&#34;&gt;Contains detailed information about traffic lights and their signalling program. &lt;b&gt;Currently not used&lt;/b&gt;.&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Route&lt;/code&gt;&lt;/td&gt;
&lt;td style=&#34;text-align:left&#34;&gt;Contains a list of all routes known for the simulation scenario. All routes referenced in the &lt;code&gt;Mapping&lt;/code&gt; configuration must be presentin this table.&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Building&lt;/code&gt; &lt;br&gt;&lt;code&gt;Corner&lt;/code&gt; &lt;br&gt;&lt;code&gt;Wall&lt;/code&gt;&lt;/td&gt;
&lt;td style=&#34;text-align:left&#34;&gt;Provides information about buildings alongside the road network, e.g. for visualization purposes or sophisticated communication simulation models.&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;Version&lt;/code&gt;&lt;/td&gt;
&lt;td style=&#34;text-align:left&#34;&gt;Contains the version of the Eclipse MOSAIC installation which was initially used to create the database.&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;h3 id=&#34;road-network-model&#34;&gt;Road network model&lt;/h3&gt;
&lt;p&gt;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 &lt;code&gt;node&lt;/code&gt; is either a junction or describes the geometry of a road. A &lt;code&gt;connection&lt;/code&gt; 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 &lt;code&gt;way&lt;/code&gt;, which may
consist of various connections. A way contains further properties, such as the maximum speed or the type of the road.&lt;/p&gt;
&lt;figure id=&#34;figure-nodes-and-connections-of-the-road-network&#34;&gt;
&lt;a data-fancybox=&#34;&#34; href=&#34;../images/node-connections.jpeg&#34; data-caption=&#34;Nodes and connections of the road network&#34;&gt;
&lt;img src=&#34;../images/node-connections.jpeg&#34; alt=&#34;&#34; width=&#34;50%&#34; &gt;
&lt;/a&gt;
&lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
Nodes and connections of the road network
&lt;/figcaption&gt;
&lt;/figure&gt;
&lt;p&gt;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 &lt;code&gt;aaa_bbb_ccc&lt;/code&gt;):&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;code&gt;aaa&lt;/code&gt; - ID of the originating way&lt;/li&gt;
&lt;li&gt;&lt;code&gt;bbb&lt;/code&gt; - ID of the node the connection starts at.&lt;/li&gt;
&lt;li&gt;&lt;code&gt;ccc&lt;/code&gt; - ID of the node the connection ends in.&lt;/li&gt;
&lt;/ul&gt;
&lt;figure id=&#34;figure-id-of-connection-in-road-network&#34;&gt;
&lt;a data-fancybox=&#34;&#34; href=&#34;../images/connections.jpeg&#34; data-caption=&#34;ID of connection in road network&#34;&gt;
&lt;img src=&#34;../images/connections.jpeg&#34; alt=&#34;&#34; width=&#34;50%&#34; &gt;
&lt;/a&gt;
&lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
ID of connection in road network
&lt;/figcaption&gt;
&lt;/figure&gt;
</description>
</item>
<item>
<title></title>
<link>https://staging.eclipse.org/mosaic/group/fokus/</link>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://staging.eclipse.org/mosaic/group/fokus/</guid>
<description></description>
</item>
<item>
<title>File Output Generator</title>
<link>https://staging.eclipse.org/mosaic/docs/visualization/filevis/</link>
<pubDate>Sun, 05 May 2019 00:00:00 +0100</pubDate>
<guid>https://staging.eclipse.org/mosaic/docs/visualization/filevis/</guid>
<description>&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;One example output could be the following:&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-csv&#34;&gt;CELL_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
&lt;/code&gt;&lt;/pre&gt;
&lt;h2 id=&#34;configuring-the-fileoutput&#34;&gt;Configuring the FileOutput&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;The main configuration file is located at &lt;code&gt;&amp;lt;mosaic-root&amp;gt;/scenarios/&amp;lt;scenarioName&amp;gt;/output/output_config.xml&lt;/code&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h4 id=&#34;basic-configuration&#34;&gt;Basic configuration&lt;/h4&gt;
&lt;p&gt;The following listing shows a basic example for the configuration of the FileOutput:&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-xml&#34;&gt;&amp;lt;?xml version=&amp;quot;1.0&amp;quot; encoding=&amp;quot;UTF-8&amp;quot;?&amp;gt;
&amp;lt;output id=&amp;quot;fileoutput&amp;quot; enabled=&amp;quot;true&amp;quot; update=&amp;quot;5&amp;quot; loader=&amp;quot;org.eclipse.mosaic.fed.output.generator.file.FileOutputLoader&amp;quot;&amp;gt;
&amp;lt;filename&amp;gt;output.csv&amp;lt;/filename&amp;gt;
&amp;lt;directory&amp;gt;.&amp;lt;/directory&amp;gt;
&amp;lt;separator&amp;gt;;&amp;lt;/separator&amp;gt;
&amp;lt;subscriptions&amp;gt;
&amp;lt;subscription id=&amp;quot;...&amp;quot;&amp;gt;
...
&amp;lt;/subscription&amp;gt;
...
&amp;lt;/subscriptions&amp;gt;&amp;gt;
&amp;lt;/output&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;&lt;em&gt;Basic configuration parameters for FileOutput&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;The usage of the parameters is described in the following table:&lt;/p&gt;
&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Parameter&lt;/th&gt;
&lt;th&gt;Usage&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;id&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;Sets the id for the output&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;enabled&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;If set to &amp;ldquo;false&amp;rdquo;, output is not used (default value is &amp;ldquo;true&amp;rdquo;)&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;update&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;Sets the update interval in seconds for the output&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;start&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;Sets the start time in seconds for output generation. This has nothing to do with the run time of the actual simulation&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;end&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;Sets the end time in seconds for output generation. This has nothing to do with the run time of the actual simulation&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;loader&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;Sets where the output is loaded from using the Java-class (see previous listing)&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;p&gt;&lt;em&gt;Basic Configuration of file output&lt;/em&gt;&lt;/p&gt;
&lt;h4 id=&#34;interaction-record&#34;&gt;Interaction record&lt;/h4&gt;
&lt;p&gt;Each interaction record is derived from a certain interaction type and composed of several entries,which are separated by Element &lt;code&gt;separator&lt;/code&gt;.&lt;/p&gt;
&lt;p&gt;The configuration of the file output is explained at the example of the &lt;code&gt;VehicleUpdates&lt;/code&gt; interaction:&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-xml&#34;&gt;&amp;lt;subscription id=&amp;quot;VehicleUpdates&amp;quot; enabled=&amp;quot;true&amp;quot;&amp;gt;
&amp;lt;entries&amp;gt;
&amp;lt;entry&amp;gt;&amp;quot;UPDATE_VEHICLE&amp;quot;&amp;lt;/entry&amp;gt;
&amp;lt;entry&amp;gt;Time&amp;lt;/entry&amp;gt;
&amp;lt;entry&amp;gt;Updated:Name&amp;lt;/entry&amp;gt;
&amp;lt;entry&amp;gt;Updated:Speed&amp;lt;/entry&amp;gt;
&amp;lt;entry&amp;gt;Updated:Position.Latitude&amp;lt;/entry&amp;gt;
&amp;lt;entry&amp;gt;Updated:Position.Longitude&amp;lt;/entry&amp;gt;
&amp;lt;/entries&amp;gt;
&amp;lt;/subscription&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;&lt;em&gt;Specific Configuration for interaction&lt;/em&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Attribute &lt;code&gt;id&lt;/code&gt; indicates the interaction type, namely the class name of the interaction.&lt;/li&gt;
&lt;li&gt;The element &lt;code&gt;entries&lt;/code&gt; defines the format and content of the handled subscription record.&lt;/li&gt;
&lt;li&gt;The element &lt;code&gt;entries&lt;/code&gt; is composed of several sub-elements &lt;code&gt;entry&lt;/code&gt;, which correspond to columns of a subscription
record and the sequence of the columns is the same as that of sub-elements entry.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;In total, there are three basic types of entries:&lt;/p&gt;
&lt;h4 id=&#34;constant&#34;&gt;Constant&lt;/h4&gt;
&lt;p&gt;Every quoted entry is defined as a constant. The content inside the quotation will be directly written
into each corresponding interaction record.&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-xml&#34;&gt;&amp;lt;entry&amp;gt;&amp;quot;UPDATE_VEHICLE&amp;quot;&amp;lt;/entry&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;&lt;em&gt;An example for constant type entry&lt;/em&gt;&lt;/p&gt;
&lt;h4 id=&#34;basic-method&#34;&gt;Basic method&lt;/h4&gt;
&lt;p&gt;The Basic method type accesses values of the interaction object by using the appropriate &lt;code&gt;getXXX()&lt;/code&gt; methods. For an entry, the
root object for method invoking is the corresponding interaction class, here &lt;code&gt;VehicleUpdates&lt;/code&gt;. As this object provides
the simulation time by calling the getter method &lt;code&gt;getTime()&lt;/code&gt;, the entry &lt;code&gt;Time&lt;/code&gt; retrieves the requested value.
If a null object is returned before the last method of cascaded methods is invoked, then &lt;code&gt;null&lt;/code&gt; will be written
to the corresponding field.&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-xml&#34;&gt;&amp;lt;entry&amp;gt;Time&amp;lt;/entry&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;&lt;em&gt;An example for constant type entry&lt;/em&gt;&lt;/p&gt;
&lt;h4 id=&#34;iteration&#34;&gt;Iteration&lt;/h4&gt;
&lt;pre&gt;&lt;code class=&#34;language-xml&#34;&gt;&amp;lt;entry&amp;gt;Updated:Id&amp;lt;/entry&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;&lt;em&gt;An example for method type entry with iteration&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;The first part of this example is &lt;code&gt;Updated&lt;/code&gt; , which means to invoke the getUpdated method of class
&lt;code&gt;VehicleUpdates&lt;/code&gt;. Then a list of &lt;code&gt;VehicleInfo&lt;/code&gt; objects is returned. The character &lt;code&gt;:&lt;/code&gt; indicates the iteration,
which means that for each of the &lt;code&gt;VehicleInfo&lt;/code&gt; objects in the returned list the &lt;code&gt;getId&lt;/code&gt; method is invoked.&lt;/p&gt;
&lt;h4 id=&#34;cascading&#34;&gt;Cascading&lt;/h4&gt;
&lt;pre&gt;&lt;code class=&#34;language-xml&#34;&gt;&amp;lt;entry&amp;gt;Updated:Position.Latitude&amp;lt;/entry&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;&lt;em&gt;An example for method type entry with iteration and cascading&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;In this example, there is a dot operation, which is a cascade operation. Here &lt;code&gt;getPosition&lt;/code&gt; method of &lt;code&gt;VehicleInfo&lt;/code&gt;
class is called and a &lt;code&gt;GlobalPosition&lt;/code&gt; object is returned. Then we continuously invoke the &lt;code&gt;getLatitude&lt;/code&gt;
method of this &lt;code&gt;GlobalPosition&lt;/code&gt; object.&lt;/p&gt;
&lt;h4 id=&#34;extended-method&#34;&gt;Extended Method&lt;/h4&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-xml&#34;&gt;&amp;lt;entry&amp;gt;TimeInSec&amp;lt;/entry&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;&lt;em&gt;An example for simple extended method type entry&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;With existing methods of &lt;code&gt;VehicleUpdates&lt;/code&gt; and its super class &lt;code&gt;Interaction&lt;/code&gt;, we cannot get the timestamp of
a interaction in second. (only &lt;code&gt;Interaction.getTime&lt;/code&gt;, which returns a time in ns, is available). Here, &lt;code&gt;getTimeInSec&lt;/code&gt;
is a method extension for &lt;code&gt;Interaction&lt;/code&gt; class. The extended method set will be listed later.&lt;/p&gt;
&lt;h2 id=&#34;further-details&#34;&gt;Further details&lt;/h2&gt;
&lt;p&gt;The method type of entry definition supports cascaded iteration as follows:&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-xml&#34;&gt;&amp;lt;entry&amp;gt;List1:List2:Id&amp;lt;/entry&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;&lt;em&gt;An example for cascaded iteration&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;It is possible to handle several different iterating operations, coming from the entry definition:&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-xml&#34;&gt;&amp;lt;entry&amp;gt;Senders:Id&amp;lt;/entry&amp;gt;
&amp;lt;entry&amp;gt;Receivers:Id&amp;lt;/entry&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;&lt;em&gt;An example for multi-level iteration&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;&lt;code&gt;getSenders()&lt;/code&gt; and &lt;code&gt;getReceivers()&lt;/code&gt; are two different iterations. In this case, a combination of both Ids from
the lists will be generated. The result may look like this:&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-csv&#34;&gt;sender1, receiver1
sender1, receiver2
sender2, receiver1
sender2, receiver2
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;&lt;em&gt;Output result of the above listing&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;Note: the longest matched prefix will be considered as the same iterating operation, which means they are in the same level of iteration structure.&lt;/p&gt;
&lt;h2 id=&#34;additional-features&#34;&gt;Additional features&lt;/h2&gt;
&lt;h4 id=&#34;limit-output-on-time-frame&#34;&gt;Limit output on time frame&lt;/h4&gt;
&lt;p&gt;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 &lt;code&gt;start&lt;/code&gt; and &lt;code&gt;end&lt;/code&gt; attributes accordingly:&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-xml&#34;&gt;&amp;lt;?xml version=&amp;quot;1.0&amp;quot; encoding=&amp;quot;UTF-8&amp;quot;?&amp;gt;
&amp;lt;output id=&amp;quot;fileoutput&amp;quot; enabled=&amp;quot;true&amp;quot;
start=&amp;quot;300&amp;quot; end=&amp;quot;1000&amp;quot; update=&amp;quot;5&amp;quot;
loader=&amp;quot;org.eclipse.mosaic.fed.output.generator.file.FileOutputLoader&amp;quot;&amp;gt;
...
&amp;lt;/output&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;&lt;em&gt;An example for restricting output generation of interactions within a time frame&lt;/em&gt;&lt;/p&gt;
&lt;h4 id=&#34;compress-output&#34;&gt;Compress Output&lt;/h4&gt;
&lt;p&gt;The tag &lt;code&gt;&amp;lt;write&amp;gt;file+compress&amp;lt;/write&amp;gt;&lt;/code&gt; 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.&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-xml&#34;&gt;&amp;lt;output id=&amp;quot;output&amp;quot; loader=&amp;quot;org.eclipse.mosaic.fed.output.generator.file.FileOutputLoader&amp;quot;&amp;gt;
&amp;lt;write&amp;gt;file+compress&amp;lt;/write&amp;gt;
...
&amp;lt;/output&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
</description>
</item>
<item>
<title>Eclipse MOSAIC Application Simulator</title>
<link>https://staging.eclipse.org/mosaic/docs/simulators/application_simulator/</link>
<pubDate>Sun, 05 May 2019 00:00:00 +0100</pubDate>
<guid>https://staging.eclipse.org/mosaic/docs/simulators/application_simulator/</guid>
<description>&lt;p&gt;The &lt;strong&gt;Application Simulator&lt;/strong&gt; 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.&lt;/p&gt;
&lt;h3 id=&#34;folder-structure&#34;&gt;Folder Structure&lt;/h3&gt;
&lt;pre&gt;&lt;code class=&#34;language-plaintext&#34;&gt;└─ &amp;lt;scenario_name&amp;gt;
├─ application
| ├─ YourApplication.jar
| ├─ application_config.json ............. Configuration file for the ambassador.
| └─ &amp;lt;scenario_name&amp;gt;.db .................. Database file for navigation.
└─ mapping
└─ mapping_config.json ................. Configuration file for the ambassador.
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;This ambassador can be configured with a configuration file. The specific path is
&lt;code&gt;&amp;lt;scenario_name&amp;gt;/application/application_config.json&lt;/code&gt;. However, it is not necessary to provide such file.&lt;/p&gt;
&lt;h3 id=&#34;installation&#34;&gt;Installation&lt;/h3&gt;
&lt;p&gt;This simulator does not need to be installed. It is delivered as part of the Eclipse MOSAIC installation package.&lt;/p&gt;
&lt;h3 id=&#34;overview&#34;&gt;Overview&lt;/h3&gt;
&lt;p&gt;Each simulation unit (e.g. vehicle, RSU, traffic light ..) can have different applications (depending on their application
&lt;a href=&#34;https://staging.eclipse.org/mosaic/mosaic/docs/simulators/application_mapping/&#34;&gt;
Mapping
&lt;/a&gt;
. The applications
for the units are basically compiled JAVA classes, which &lt;strong&gt;extend&lt;/strong&gt; the abstract class &lt;code&gt;AbstractApplication&lt;/code&gt;. Those
classes have to be deployed as pre-compiled JAR files into the &lt;code&gt;application&lt;/code&gt; folder of the simulated scenario.&lt;/p&gt;
&lt;figure id=&#34;figure-overview-of-interaction-between-applications-and-the-units-operating-system-with-its-modules-an-example-v2x-message-propagation-is-presented&#34;&gt;
&lt;a data-fancybox=&#34;&#34; href=&#34;../images/application_overview.svg&#34; data-caption=&#34;Overview of interaction between applications and the unit&amp;rsquo;s operating system with its modules. An example V2X message propagation is presented.&#34;&gt;
&lt;img src=&#34;../images/application_overview.svg&#34; alt=&#34;&#34; &gt;
&lt;/a&gt;
&lt;figcaption&gt;
Overview of interaction between applications and the unit&amp;rsquo;s operating system with its modules. An example V2X message propagation is presented.
&lt;/figcaption&gt;
&lt;/figure&gt;
&lt;h4 id=&#34;application-operating-system&#34;&gt;Application Operating System&lt;/h4&gt;
&lt;p&gt;The &lt;code&gt;AbstractApplication&lt;/code&gt; possesses a unit-specific &lt;code&gt;OperatingSystem&lt;/code&gt;, 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 &lt;code&gt;slowDown()&lt;/code&gt; for vehicles).&lt;/p&gt;
&lt;p&gt;As the interaction types for navigation (retrieving road network information and calculating routes) and communication (preparing and
sending messages) are more complex, they are separated into the specific modules &lt;code&gt;NavigationModule&lt;/code&gt; (Navigation + Routing for
vehicles) / &lt;code&gt;RoutingModule&lt;/code&gt; (Routing-only for static units) and &lt;code&gt;AdHocModule&lt;/code&gt; / &lt;code&gt;CellModule&lt;/code&gt; with APIs dedicated to their purpose.&lt;/p&gt;
&lt;p&gt;The following table lists all modules a unit&amp;rsquo;s operating system could provide.&lt;/p&gt;
&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Module&lt;/th&gt;
&lt;th&gt;Description&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;NavigationModule&lt;/td&gt;
&lt;td&gt;Full featured access to the central navigation component for vehicles&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;RoutingModule&lt;/td&gt;
&lt;td&gt;Access to routing functionalities for static units as RSUs&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;AdHocModule&lt;/td&gt;
&lt;td&gt;Communication via ad hoc mode, using WIFI or ITS G5 specific means (e.g. for addressing)&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;CellModule&lt;/td&gt;
&lt;td&gt;Communication via cellular services (different configuration / addressing modes)&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;blockquote&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;/strong&gt; The presented communication modules &lt;code&gt;AdHocModule&lt;/code&gt;, &lt;code&gt;CellModule&lt;/code&gt; are used for the sending part of a transmission. The message
reception is realized by Application Interfaces provided by the &lt;code&gt;CommunicationApplication&lt;/code&gt;.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;h4 id=&#34;application-interfaces&#34;&gt;Application Interfaces&lt;/h4&gt;
&lt;p&gt;Application interfaces handle call-backs to incoming events via their methods, like &lt;code&gt;onVehicleUpdated()&lt;/code&gt;, 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
&amp;ldquo;Provides&amp;rdquo; column. The elementary interface (&lt;code&gt;Application&lt;/code&gt;) provides the methods &lt;code&gt;onStartup()&lt;/code&gt;, &lt;code&gt;onShutdown()&lt;/code&gt;. Implementation details
are given in
&lt;a href=&#34;https://staging.eclipse.org/mosaic/mosaic/docs/develop_applications/&#34;&gt;
Development of applications
&lt;/a&gt;
.&lt;/p&gt;
&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Interface&lt;/th&gt;
&lt;th&gt;Applicable to&lt;/th&gt;
&lt;th&gt;Provides&lt;/th&gt;
&lt;th&gt;Description&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;Application / AbstractApplication&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;&lt;em&gt;all&lt;/em&gt;&lt;/td&gt;
&lt;td&gt;&lt;code&gt;onStartup&lt;/code&gt;, &lt;code&gt;onShutdown&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;Elementary application class providing an operating system&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;ConfigurableApplication&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;&lt;em&gt;all&lt;/em&gt;&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;Basic application class providing an operating system and a configuration, which automatically loaded from a JSON file.&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;CommunicationApplication&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;&lt;em&gt;all&lt;/em&gt;&lt;/td&gt;
&lt;td&gt;&lt;code&gt;onMessageReceived&lt;/code&gt;, &lt;code&gt;onAcknowledgementReceived&lt;/code&gt;, &lt;code&gt;onCamBuilding&lt;/code&gt;, &lt;code&gt;onMessageTransmitted&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;All applications that implement some form of V2X communication are to implement this interface.&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;VehicleApplication&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;vehicle&lt;/td&gt;
&lt;td&gt;&lt;code&gt;onVehicleUpdated&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;General vehicle funtionality&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;ElectricVehicleApplication&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;vehicle&lt;/td&gt;
&lt;td&gt;&lt;code&gt;onBatteryStateUpdated&lt;/code&gt;, &lt;code&gt;onChargingRequestRejected&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;Electric vehicle functionality&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;TrafficSignAwareApplication&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;vehicle&lt;/td&gt;
&lt;td&gt;&lt;code&gt;onTrafficSignInvalidated&lt;/code&gt;, &lt;code&gt;onTrafficSignNoticed&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;Used by vehicles which are aware of traffic signs.&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;TrafficLightApplication&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;traffic light&lt;/td&gt;
&lt;td&gt;&lt;code&gt;onTrafficLightGroupUpdated&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;Traffic light functionality&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;TrafficManagementCenterApplication&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;TMC&lt;/td&gt;
&lt;td&gt;&lt;code&gt;onInductionLoopUpdated&lt;/code&gt;, &lt;code&gt;onLaneAreaDetectorUpdated&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;Traffic management functionality&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;MosaicApplication&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;&lt;em&gt;all&lt;/em&gt;&lt;/td&gt;
&lt;td&gt;&lt;code&gt;onSumoTraciResponded&lt;/code&gt;, &lt;code&gt;onInteractionReceived&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;Features that involve customized RTI-interactions of MOSAIC&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;/strong&gt; A roadside unit (RSU) is the most unit and usually communicates only. Thus, an RSU application implements &lt;code&gt;CommunicationApplication&lt;/code&gt;.&lt;/p&gt;
&lt;hr&gt;
&lt;h3 id=&#34;configuration&#34;&gt;Configuration&lt;/h3&gt;
&lt;p&gt;The Application simulator is configured in the file &lt;code&gt;&amp;lt;scenario_name&amp;gt;/application/application_config.json&lt;/code&gt;:&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;{
&amp;quot;messageCacheTime&amp;quot;: &amp;quot;30s&amp;quot;,
&amp;quot;minimalPayloadLength&amp;quot;: 200,
&amp;quot;encodePayloads&amp;quot;: true,
&amp;quot;navigationConfiguration&amp;quot; : {
&amp;quot;type&amp;quot;: &amp;quot;database&amp;quot;
}
}
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Furthermore, depending on the deployed applications, the applications itself may offer configuration options
in custom configuration files (e.g. &lt;code&gt;ETSIApplication.json&lt;/code&gt; or &lt;code&gt;ETSIApplication_veh_0.json&lt;/code&gt;).&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id=&#34;basic-applications&#34;&gt;Basic Applications&lt;/h2&gt;
&lt;p&gt;Eclipse MOSAIC is shipped with several example applications which can be loaded on the vehicles. Next to the applications shipped with
the tutorial scenarios &lt;strong&gt;Barnim&lt;/strong&gt; and &lt;strong&gt;Tiergarten&lt;/strong&gt;, there are further example applications to be found on our website.&lt;/p&gt;
&lt;p&gt;Additionally, we provide an ETSI conform application which implement specific CAM generation rules for vehicles
(&lt;code&gt;org.eclipse.mosaic.fed.application.app.etsi.VehicleCamSendingApp&lt;/code&gt;), which is described in the following:&lt;/p&gt;
&lt;h4 id=&#34;etsi-application-for-vehicles&#34;&gt;ETSI Application for vehicles&lt;/h4&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Currently, the default configuration (&lt;code&gt;ETSIApplication.json&lt;/code&gt;) for the ETSI application looks like this:&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;{
/* The maximum time offset (here 1 second) of sending CA-messages
* (the offset will be different for every single vehicle to avoid interference) */
&amp;quot;maxStartOffset&amp;quot;: 1000000000,
/* CAMs are sent at most every 1 second */
&amp;quot;minInterval&amp;quot;: 100000000,
/* CAMs are sent at least every 1 second */
&amp;quot;maxInterval&amp;quot;: 1000000000,
/* CAMs are sent when the position of the vehicle changes at least about 4 meters */
&amp;quot;positionChange&amp;quot;: 4,
/* CAMs are sent when the heading of the vehicle changes at least about 4 degrees */
&amp;quot;headingChange&amp;quot;: 4,
/* CAMs are sent when the velocity of the vehicle changes at least about 0.5 m/s */
&amp;quot;velocityChange&amp;quot;: 0.5
}
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;The CAMs sent out by this application consist of four parts:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Header with generic information&lt;/li&gt;
&lt;li&gt;MessageBody&lt;/li&gt;
&lt;li&gt;TaggedValue list&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;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.&lt;/p&gt;
</description>
</item>
<item>
<title>Simulation Entities and Application Mapping</title>
<link>https://staging.eclipse.org/mosaic/docs/simulators/application_mapping/</link>
<pubDate>Sun, 05 May 2019 00:00:00 +0100</pubDate>
<guid>https://staging.eclipse.org/mosaic/docs/simulators/application_mapping/</guid>
<description>&lt;p&gt;Closely related to the Application Simulator, the &lt;strong&gt;Mapping&lt;/strong&gt; Ambassador is used for the initial choreography of a simulation.
It defines two major aspects for the simulation units:&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;number, properties, position (e.g. of RSUs, traffic lights) or initial routes (of vehicles, simulated in a traffic/vehicle simulator)&lt;/li&gt;
&lt;li&gt;specific application(s) to be &amp;ldquo;mapped&amp;rdquo; on the simulation units and simulated in the Application Simulation&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;The JSON based configuration is located in &lt;code&gt;&amp;lt;scenario_name&amp;gt;/mapping/mapping_config.json&lt;/code&gt;.&lt;/p&gt;
&lt;h3 id=&#34;configuration&#34;&gt;Configuration&lt;/h3&gt;
&lt;p&gt;The Mapping configuration is divided into different parts:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Pre Definitions of &lt;code&gt;prototypes&lt;/code&gt; and &lt;code&gt;deviations&lt;/code&gt;&lt;/li&gt;
&lt;li&gt;Entity Definitions of &lt;code&gt;vehicles&lt;/code&gt;, &lt;code&gt;rsus&lt;/code&gt;, &lt;code&gt;tls&lt;/code&gt; &lt;code&gt;servers&lt;/code&gt; and &lt;code&gt;tmcs&lt;/code&gt;&lt;/li&gt;
&lt;li&gt;Advanced Vehicle Definitions (including route generation) in &lt;code&gt;matrixMappers&lt;/code&gt;&lt;/li&gt;
&lt;li&gt;Common Definitions in &lt;code&gt;config&lt;/code&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h4 id=&#34;prototypes&#34;&gt;Prototypes&lt;/h4&gt;
&lt;p&gt;&lt;code&gt;prototypes&lt;/code&gt; 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.&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;&amp;quot;prototypes&amp;quot;: [
{
&amp;quot;name&amp;quot;: &amp;quot;CamVehicle&amp;quot;,
&amp;quot;accel&amp;quot;: 2.6,
&amp;quot;decel&amp;quot;: 4.5,
&amp;quot;length&amp;quot;: 5.00,
&amp;quot;maxSpeed&amp;quot;: 70.0,
&amp;quot;applications&amp;quot;: [ &amp;quot;org.eclipse.mosaic.fed.application.app.etsi.VehicleCamSendingApp&amp;quot; ]
}
]
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Prototypes can be created for all types of entities. Next to the list of &lt;code&gt;applications&lt;/code&gt; which is available for all types of entities,
vehicle types provide various other parameters to be adjusted.&lt;/p&gt;
&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Parameter&lt;/th&gt;
&lt;th&gt;Description&lt;/th&gt;
&lt;th&gt;Deviation&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;vehicleClass&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;The class of the vehicle, e.g. &lt;code&gt;Car&lt;/code&gt;, &lt;code&gt;ElectricVehicle&lt;/code&gt;, &lt;code&gt;EmergencyVehicle&lt;/code&gt;, &lt;code&gt;Bicycle&lt;/code&gt;, &lt;code&gt;HeavyGoodsVehicle&lt;/code&gt;, and more.&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;accel&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;The maximum acceleration of the vehicle in $m/s^2$.&lt;/td&gt;
&lt;td&gt;Yes&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;decel&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;The maximum deceleration of the vehicle in $m/s^2$, e.g. when stopping for traffic lights.&lt;/td&gt;
&lt;td&gt;Yes&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;emergencyDecel&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;The maximum deceleration of the vehicle in $m/s^2$, in order to avoid accidents.&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;length&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;The length of the vehicle in $m$.&lt;/td&gt;
&lt;td&gt;Yes&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;maxSpeed&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;The maximum speed of the vehicle in $m/s$.&lt;/td&gt;
&lt;td&gt;Yes&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;minGap&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;The minimum gap towards the leader in $m$, i.e. the space in front in a traffic jam.&lt;/td&gt;
&lt;td&gt;Yes&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;sigma&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;The driver&amp;rsquo;s imperfection $[0,1]$.&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;tau&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;The reaction time (or time headway) of the vehicle in $s$.&lt;/td&gt;
&lt;td&gt;Yes&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;speedFactor&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;This factor is used to determine the speed limit to comply on roads, e.g. &lt;code&gt;1.1&lt;/code&gt; would exceed the speed limit by 10%.&lt;/td&gt;
&lt;td&gt;Yes&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;laneChangeMode&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;The lane changing behavior of the vehicle: &lt;code&gt;COOPERATIVE&lt;/code&gt;. &lt;code&gt;CAUTIOUS&lt;/code&gt;, &lt;code&gt;AGGRESSIVE&lt;/code&gt;, &lt;code&gt;PASSIVE&lt;/code&gt;, &lt;code&gt;OFF&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;applications&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;The list of applications to map onto this vehicle type.&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;p&gt;For the majority of the parameters above (see column &amp;ldquo;Deviation&amp;rdquo;), 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 &lt;code&gt;deviations&lt;/code&gt;
attribute must be added to the type:&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;&amp;quot;prototypes&amp;quot;: [
{
&amp;quot;name&amp;quot;: &amp;quot;Car&amp;quot;,
&amp;quot;length&amp;quot;: 5.0,
&amp;quot;maxSpeed&amp;quot;: 70.0,
&amp;quot;deviations&amp;quot;: {
&amp;quot;length&amp;quot;: 1.2,
&amp;quot;maxSpeed&amp;quot;: 5.0
}
}
]
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;According to the config above, the basic parameter value conforms to the expected value, and the given value in the &lt;code&gt;deviations&lt;/code&gt;
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$.&lt;/p&gt;
&lt;h4 id=&#34;entities&#34;&gt;Entities&lt;/h4&gt;
&lt;p&gt;&lt;strong&gt;Vehicles&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;The &lt;code&gt;vehicles&lt;/code&gt;-section is the centerpiece of the Mapping configuration. It defines the departures (times and number),
routes, and types of the vehicles.&lt;/p&gt;
&lt;p&gt;Each spawner in this list generates a traffic stream of vehicles on a certain &lt;code&gt;route&lt;/code&gt;. The vehicles stream begins at &lt;code&gt;startingTime&lt;/code&gt; and
generates vehicles until &lt;code&gt;maxNumberVehicles&lt;/code&gt; is reached. The time between two consecutively vehicles is implicitly given by the
&lt;code&gt;targetFlow&lt;/code&gt; property, which defines how many vehicles per hour are going to be spawned.&lt;/p&gt;
&lt;p&gt;Each vehicle spawner must refer to at least one vehicle type (&lt;code&gt;types&lt;/code&gt;). A vehicle type must either refer to a type from the &lt;code&gt;prototypes&lt;/code&gt;
section by using its &lt;code&gt;name&lt;/code&gt;, or be defined as a completely new vehicle type with all necessary parameters. If more than one vehicle type
is referenced in the &lt;code&gt;types&lt;/code&gt; attribute, &lt;code&gt;weight&lt;/code&gt;s 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.&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;Note: if at least one vehicle type has a weight defined, all types without a defined weight are ignored.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;&amp;quot;vehicles&amp;quot;: [
{
&amp;quot;startingTime&amp;quot;: 5.0,
&amp;quot;targetFlow&amp;quot;: 1800,
&amp;quot;maxNumberVehicles&amp;quot;: 120,
&amp;quot;route&amp;quot;: &amp;quot;1&amp;quot;,
&amp;quot;types&amp;quot;: [
{
&amp;quot;name&amp;quot;: &amp;quot;CAMVehicle&amp;quot;,
&amp;quot;weight&amp;quot;: 0.1
},
{
&amp;quot;name&amp;quot;: &amp;quot;NormalVehicle&amp;quot;, // this vehicle has no applications
&amp;quot;applications&amp;quot;: [ ],
&amp;quot;weight&amp;quot;: 0.2
}
]
}
]
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Additional notes:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;The &lt;code&gt;route&lt;/code&gt; refers to a route usually defined in the scenario database file (&lt;code&gt;*.db&lt;/code&gt;) of the scenario.&lt;/li&gt;
&lt;li&gt;In order to define only one single vehicle to be spawned, the &lt;code&gt;maxNumberVehicles&lt;/code&gt; property can be set to &lt;code&gt;1&lt;/code&gt;.&lt;/li&gt;
&lt;li&gt;By defining the &lt;code&gt;endingTime&lt;/code&gt; property, the flow is stopped from being generated when the given simulation time is reached.&lt;/li&gt;
&lt;li&gt;By defining the &lt;code&gt;spawningMode&lt;/code&gt; to one of the following values, the departure time of the individual vehicles can be adjusted:
&lt;ul&gt;
&lt;li&gt;&lt;code&gt;CONSTANT&lt;/code&gt; - default case, all vehicles have equal time distance to match &lt;code&gt;target_flow&lt;/code&gt;.&lt;/li&gt;
&lt;li&gt;&lt;code&gt;POISSON&lt;/code&gt; - vehicles depart within a Poisson distribution, resulting in a more natural traffic flow.&lt;/li&gt;
&lt;li&gt;&lt;code&gt;GROW&lt;/code&gt; - the flow of departing vehicles increases linear up to &lt;code&gt;target_flow&lt;/code&gt;.&lt;/li&gt;
&lt;li&gt;&lt;code&gt;SHRINK&lt;/code&gt; - the flow of departing vehicles decreases linear starting at &lt;code&gt;target_flow&lt;/code&gt;.&lt;/li&gt;
&lt;li&gt;&lt;code&gt;GROW_AND_SHRINK&lt;/code&gt; - the flow of departing vehicles increases up to &lt;code&gt;target_flow&lt;/code&gt; and decreases afterwards.&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;By defining the &lt;code&gt;laneSelectionMode&lt;/code&gt; to one the following values, the selection of the departure lane can be adjusted:
&lt;ul&gt;
&lt;li&gt;&lt;code&gt;DEFAULT&lt;/code&gt; - selects the lane for the next vehicle based on the list of given &lt;code&gt;lanes&lt;/code&gt; in a roundrobin manner.&lt;/li&gt;
&lt;li&gt;&lt;code&gt;ROUNDROBIN_HIGHWAY&lt;/code&gt; - trucks will be spawned on the rightmost lane, all other vehicles according to &lt;code&gt;DEFAULT&lt;/code&gt;.&lt;/li&gt;
&lt;li&gt;&lt;code&gt;HIGHWAY&lt;/code&gt; - trucks will be spawned on the rightmost lane, all other vehicles according to &lt;code&gt;BEST&lt;/code&gt;.&lt;/li&gt;
&lt;li&gt;&lt;code&gt;RANDOM&lt;/code&gt; - the vehicle will be placed randomly on one of the available lanes of the road.&lt;/li&gt;
&lt;li&gt;&lt;code&gt;FREE&lt;/code&gt; - the vehicle will be placed on a free lane of the road.&lt;/li&gt;
&lt;li&gt;&lt;code&gt;BEST&lt;/code&gt; - the vehicle will be placed on the best lane of the road, according to the current traffic situation and departure speed.&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;strong&gt;Road Side Units&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;The &lt;code&gt;rsus&lt;/code&gt;-section offers the possibility to define instances of application supported Road Side Units (RSU)s and place them on a
defined position (&lt;code&gt;lat&lt;/code&gt;, &lt;code&gt;lon&lt;/code&gt; coordinates). Referring to &lt;code&gt;prototype&lt;/code&gt; definitions with simply specifying its name in the &lt;code&gt;name&lt;/code&gt;
property will automatically fill in relevant properties of the RSU.&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;&amp;quot;rsus&amp;quot;: [
{
&amp;quot;lat&amp;quot;: 52.65027,
&amp;quot;lon&amp;quot;: 13.54500,
&amp;quot;name&amp;quot;: &amp;quot;WeatherServer&amp;quot;,
&amp;quot;applications&amp;quot;: [ &amp;quot;org.eclipse.mosaic.app.tutorial.WeatherServerApp&amp;quot; ]
}
]
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;&lt;strong&gt;Traffic Lights&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;In the &lt;code&gt;trafficLights&lt;/code&gt;-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 &lt;code&gt;tlGroupId&lt;/code&gt;-property allows mapping of applications to the traffic light groups, referring them by Id.&lt;/p&gt;
&lt;p&gt;Alternatively, the definition of the &lt;code&gt;weight&lt;/code&gt;-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.&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;&amp;quot;trafficLights&amp;quot;: [
{
&amp;quot;tlGroupId&amp;quot;: &amp;quot;26704448&amp;quot;,
&amp;quot;applications&amp;quot;: [ &amp;quot;org.eclipse.mosaic.app.tutorial.TrafficLightApp&amp;quot; ]
},
{
&amp;quot;tlGroupId&amp;quot;: &amp;quot;252864802&amp;quot;,
&amp;quot;applications&amp;quot;: [ &amp;quot;org.eclipse.mosaic.app.tutorial.TrafficLightApp&amp;quot; ]
}
]
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;For more information, explained for detailed examples with different mapping options regarding traffic lights, please refer to
&lt;a href=&#34;https://staging.eclipse.org/mosaic/mosaic/docs/building_scenarios/#traffic-lights&#34;&gt;
Simulation Scenarios - Traffic Lights
&lt;/a&gt;
.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Servers&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;The &lt;code&gt;servers&lt;/code&gt;-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 &lt;code&gt;CellModule&lt;/code&gt;. Delay and transmission models are configured
in the &lt;code&gt;network.json&lt;/code&gt; of the cell module (see
&lt;a href=&#34;https://staging.eclipse.org/mosaic/mosaic/docs/simulators/network_simulator_cell/&#34;&gt;
here
&lt;/a&gt;
).&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;Note: The &lt;code&gt;group&lt;/code&gt; parameter in the mapping configuration has to match with the id in the network configuration in order to
properly function.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;&amp;quot;servers&amp;quot;: [
{
&amp;quot;name&amp;quot;: &amp;quot;MyServer&amp;quot;,
&amp;quot;group&amp;quot;: &amp;quot;TestServers&amp;quot;,
&amp;quot;applications&amp;quot;: [ &amp;quot;ServerApp1&amp;quot;, &amp;quot;ServerApp2&amp;quot; ]
}
]
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;&lt;strong&gt;Traffic Management Centers&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;The &lt;code&gt;tmc&lt;/code&gt;-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&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;&amp;quot;tmcs&amp;quot;: [
{
&amp;quot;name&amp;quot;: &amp;quot;HighwayManagement&amp;quot;,
&amp;quot;group&amp;quot;: &amp;quot;TestTmcServers&amp;quot;,
&amp;quot;applications&amp;quot;: [ &amp;quot;org.eclipse.mosaic.app.tutorial.HighwayManagementApp(&#39;3&#39;, 3)&amp;quot; ],
&amp;quot;inductionLoops&amp;quot;: [ &amp;quot;detector_0&amp;quot;, &amp;quot;detector_1&amp;quot;, &amp;quot;detector_2&amp;quot; ],
&amp;quot;laneAreaDetectors&amp;quot;: [ ]
}
]
&lt;/code&gt;&lt;/pre&gt;
&lt;blockquote&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;h4 id=&#34;use-type-distributions-in-complex-traffic-scenarios&#34;&gt;Use Type Distributions in Complex Traffic Scenarios&lt;/h4&gt;
&lt;p&gt;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 &lt;code&gt;typeDistributions&lt;/code&gt;. By doing so, it is very simple to adjust the list of types and weights at only one
place in the configuration file.&lt;/p&gt;
&lt;p&gt;Instead of defining an equal list of types and weights for each single vehicle spawner, like in this example:&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;&amp;quot;vehicles&amp;quot;: [
{
&amp;quot;startingTime&amp;quot;: 5.0,
&amp;quot;targetFlow&amp;quot;: 1800,
&amp;quot;maxNumberVehicles&amp;quot;: 120,
&amp;quot;route&amp;quot;: &amp;quot;1&amp;quot;,
&amp;quot;types&amp;quot;: [
{ &amp;quot;name&amp;quot;: &amp;quot;TypeA&amp;quot;, &amp;quot;weight&amp;quot;: 0.1 },
{ &amp;quot;name&amp;quot;: &amp;quot;TypeB&amp;quot;, &amp;quot;weight&amp;quot;: 0.9 }
]
},
{
&amp;quot;startingTime&amp;quot;: 55.0,
&amp;quot;targetFlow&amp;quot;: 1800,
&amp;quot;maxNumberVehicles&amp;quot;: 120,
&amp;quot;route&amp;quot;: &amp;quot;2&amp;quot;,
&amp;quot;types&amp;quot;: [
{ &amp;quot;name&amp;quot;: &amp;quot;TypeA&amp;quot;, &amp;quot;weight&amp;quot;: 0.1 },
{ &amp;quot;name&amp;quot;: &amp;quot;TypeB&amp;quot;, &amp;quot;weight&amp;quot;: 0.9 }
]
}
]
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;&amp;hellip; you can use &lt;code&gt;typeDistributions&lt;/code&gt; to define the distribution of types for each vehicle once and reuse them:&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;&amp;quot;typeDistributions&amp;quot;: {
&amp;quot;exampleTypeDist&amp;quot; : [
{ &amp;quot;name&amp;quot;: &amp;quot;TypeA&amp;quot;, &amp;quot;weight&amp;quot;: 0.1 },
{ &amp;quot;name&amp;quot;: &amp;quot;TypeB&amp;quot;, &amp;quot;weight&amp;quot;: 0.9 }
]
},
&amp;quot;vehicles&amp;quot;: [
{
&amp;quot;startingTime&amp;quot;: 5.0,
&amp;quot;targetFlow&amp;quot;: 1800,
&amp;quot;maxNumberVehicles&amp;quot;: 120,
&amp;quot;route&amp;quot;: &amp;quot;1&amp;quot;,
&amp;quot;typeDistribution&amp;quot;: &amp;quot;exampleTypeDist&amp;quot;
},
{
&amp;quot;startingTime&amp;quot;: 55.0,
&amp;quot;targetFlow&amp;quot;: 1800,
&amp;quot;maxNumberVehicles&amp;quot;: 120,
&amp;quot;route&amp;quot;: &amp;quot;2&amp;quot;,
&amp;quot;typeDistribution&amp;quot;: &amp;quot;exampleTypeDist&amp;quot;
}
]
&lt;/code&gt;&lt;/pre&gt;
&lt;h4 id=&#34;advanced-vehicle-spawners-with-route-generation&#34;&gt;Advanced vehicle spawners with route generation&lt;/h4&gt;
&lt;p&gt;It is also possible to define and use OD (origin-destination) matrices by adding a ODMatrixMapper to the &lt;code&gt;matrixMappers&lt;/code&gt;-list.
Each MatrixMapper consists of a list of &lt;code&gt;points&lt;/code&gt;, the vehicle-&lt;code&gt;types&lt;/code&gt; to be used and the actual flow-values (&lt;code&gt;odValues&lt;/code&gt;) between each
of the points. It is possible to define multiple matrices. This way can achieve distinctively different compositions of the vehicle flows.&lt;/p&gt;
&lt;p&gt;The MatrixMapper will be called before the actual execution of the simulation and will generate vehicle-spawners for the flow between
each of the points.&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;
&amp;quot;matrixMappers&amp;quot;: [
{
&amp;quot;points&amp;quot;: [
{
&amp;quot;name&amp;quot;: &amp;quot;CityA&amp;quot;,
&amp;quot;position&amp;quot;: {
&amp;quot;center&amp;quot;: {
&amp;quot;latitude&amp;quot;: 52,
&amp;quot;longitude&amp;quot;: 13
},
&amp;quot;radius&amp;quot;: 1000
}
},
{
&amp;quot;name&amp;quot;: &amp;quot;CityB&amp;quot;,
&amp;quot;position&amp;quot;: {
&amp;quot;center&amp;quot;: {
&amp;quot;latitude&amp;quot;: 48,
&amp;quot;longitude&amp;quot;: 10
},
&amp;quot;radius&amp;quot;: 1000
}
}
],
&amp;quot;types&amp;quot;: [
{
&amp;quot;name&amp;quot;: &amp;quot;CAMVehicle&amp;quot;
}
],
&amp;quot;odValues&amp;quot;: [
[0, 100], //100 vehicles from CityA to CityB
[200, 0] //200 vehicles from CityB to CityA
]
}
]
&lt;/code&gt;&lt;/pre&gt;
&lt;h4 id=&#34;common-configuration&#34;&gt;Common Configuration&lt;/h4&gt;
&lt;p&gt;Next to the specific configuration of prototypes and simulation entities, some general parameters can be adjusted:&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;{
&amp;quot;config&amp;quot;: {
&amp;quot;scaleTraffic&amp;quot; : 1.0,
&amp;quot;start&amp;quot;: 0,
&amp;quot;end&amp;quot;: 500,
&amp;quot;adjustStartingTimes&amp;quot;: false,
&amp;quot;randomizeFlows&amp;quot;: false,
&amp;quot;randomizeStartingTimes&amp;quot; : false,
&amp;quot;randomizeWeights&amp;quot;: false
}
}
&lt;/code&gt;&lt;/pre&gt;
&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Parameter&lt;/th&gt;
&lt;th&gt;Description&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;scaleTraffic&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;Scales the &lt;code&gt;targetFlow&lt;/code&gt; of spawned vehicles per hour as well as the &lt;code&gt;maxNumberVehicles&lt;/code&gt; by the given factor.&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;start&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;Adjusts the point in time (in $s$) to start spawning vehicles. Any vehicle spawner with a lower &lt;code&gt;startingTime&lt;/code&gt; will be ignored.&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;end&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;Adjusts the point in time (in $s$) to end spawning vehicles. Any vehicle spawner with a greater &lt;code&gt;startingTime&lt;/code&gt; will be ignored.&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;adjustStartingTimes&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;If set to &lt;code&gt;true&lt;/code&gt;, the starting time of each spawner is reduced by the value in &lt;code&gt;start&lt;/code&gt;.&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;randomizeFlows&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;If set to &lt;code&gt;true&lt;/code&gt;, the departure time of vehicles within a vehicle spawner is slightly randomized.&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;randomizeStartingTimes&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;If set to &lt;code&gt;true&lt;/code&gt;, the starting time of each vehicle spawner is slightly randomized.&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;randomizeWeights&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;If set to &lt;code&gt;true&lt;/code&gt;, each &lt;code&gt;weight&lt;/code&gt; greater than zero is slightly randomized.&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;div class=&#34;alert alert-tip&#34;&gt;
&lt;div&gt;
&lt;p&gt;Read the detailed documentation of the
&lt;a href=&#34;https://staging.eclipse.org/mosaic/mosaic/docs/mosaic_configuration/mapping_ambassador_config/&#34;&gt;
Mapping Configuration
&lt;/a&gt;
.&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;h3 id=&#34;unit-identifiers&#34;&gt;Unit Identifiers&lt;/h3&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;&lt;strong&gt;Traffic Object&lt;/strong&gt;&lt;/th&gt;
&lt;th&gt;&lt;strong&gt;Eclipse MOSAIC Internal ID&lt;/strong&gt;&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;Vehicle&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;&lt;code&gt;veh_&amp;lt;seq_nr&amp;gt;&lt;/code&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;RSU&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;&lt;code&gt;rsu_&amp;lt;seq_nr&amp;gt;&lt;/code&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;TMC&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;&lt;code&gt;tmc_&amp;lt;seq_nr&amp;gt;&lt;/code&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;Traffic Light&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;&lt;code&gt;tl_&amp;lt;group_id&amp;gt;&lt;/code&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;ul&gt;
&lt;li&gt;&lt;code&gt;seq_nr&lt;/code&gt; is the sequence number of simulated vehicles, RSUs, TMCs, each starting from zero.&lt;/li&gt;
&lt;li&gt;&lt;code&gt;group_id&lt;/code&gt; is the group id of the traffic light.&lt;/li&gt;
&lt;/ul&gt;
</description>
</item>
<item>
<title>Run a simulation with Eclipse MOSAIC</title>
<link>https://staging.eclipse.org/mosaic/docs/getting_started/run_mosaic/</link>
<pubDate>Sun, 05 May 2019 00:00:00 +0100</pubDate>
<guid>https://staging.eclipse.org/mosaic/docs/getting_started/run_mosaic/</guid>
<description>&lt;p&gt;To run a single simulation via Command Line Interface (CLI), call the Eclipse MOSAIC start script with the
following command line arguments.&lt;/p&gt;
&lt;h3 id=&#34;gnulinux&#34;&gt;GNU/Linux&lt;/h3&gt;
&lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;./mosaic.sh -s &amp;lt;scenario-name&amp;gt;
./mosaic.sh -c ./scenarios/&amp;lt;scenario_name&amp;gt;/scenario_config.json
&lt;/code&gt;&lt;/pre&gt;
&lt;h3 id=&#34;windows&#34;&gt;Windows&lt;/h3&gt;
&lt;pre&gt;&lt;code class=&#34;language-dos&#34;&gt;mosaic.bat -s &amp;lt;scenario-name&amp;gt;
mosaic.bat -c .\scenarios\&amp;lt;scenario_name&amp;gt;\scenario_config.json
&lt;/code&gt;&lt;/pre&gt;
&lt;h3 id=&#34;example&#34;&gt;Example&lt;/h3&gt;
&lt;p&gt;The following call starts the example scenario &amp;ldquo;Barnim&amp;rdquo; in Eclipse MOSAIC on a Windows machine and opens a
&lt;a href=&#34;https://staging.eclipse.org/mosaic/mosaic/docs/visualization/&#34;&gt;
Visualization in your browser
&lt;/a&gt;
:&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-dos&#34;&gt;mosaic.bat -s Barnim -v
&lt;/code&gt;&lt;/pre&gt;
&lt;figure id=&#34;figure-running-the-pre-bundled-example-scenario-barnim-with-eclipse-mosaic&#34;&gt;
&lt;a data-fancybox=&#34;&#34; href=&#34;../images/mosaic-barnim.gif&#34; data-caption=&#34;Running the pre-bundled example scenario &amp;ldquo;Barnim&amp;rdquo; with Eclipse MOSAIC&#34;&gt;
&lt;img src=&#34;../images/mosaic-barnim.gif&#34; alt=&#34;&#34; &gt;
&lt;/a&gt;
&lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
Running the pre-bundled example scenario &amp;ldquo;Barnim&amp;rdquo; with Eclipse MOSAIC
&lt;/figcaption&gt;
&lt;/figure&gt;
&lt;h3 id=&#34;cli-options&#34;&gt;CLI Options&lt;/h3&gt;
&lt;p&gt;The Eclipse MOSAIC start script supports the following arguments:&lt;/p&gt;
&lt;style&gt;
table th:first-of-type {
width: 20%;
}
table th:nth-of-type(2) {
width: 80%;
}
&lt;/style&gt;
&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th style=&#34;text-align:left&#34;&gt;Option&lt;/th&gt;
&lt;th style=&#34;text-align:left&#34;&gt;Description&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;-c&lt;/code&gt;&lt;br&gt;&lt;code&gt;--configuration&lt;/code&gt;&lt;/td&gt;
&lt;td style=&#34;text-align:left&#34;&gt;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 &lt;code&gt;&amp;lt;mosaic-root&amp;gt;/scenarios/&amp;lt;scenario_name&amp;gt;/scenario_config.json&lt;/code&gt;.&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;-s&lt;/code&gt;&lt;br&gt;&lt;code&gt;--scenario&lt;/code&gt;&lt;/td&gt;
&lt;td style=&#34;text-align:left&#34;&gt;If the main configuration file of your scenario is located in the default scenario directory of MOSAIC (i.e. in &lt;code&gt;&amp;lt;mosaic-root&amp;gt;/scenarios/&amp;lt;scenario_name&amp;gt;/scenario_config.json&lt;/code&gt;), this option can be used instead of the &lt;code&gt;-c&lt;/code&gt; option by passing only the scenario name &lt;code&gt;-s &amp;lt;scenario_name&amp;gt;&lt;/code&gt;.&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;-w&lt;/code&gt;&lt;br&gt;&lt;code&gt;--watchdog-interval&lt;/code&gt;&lt;/td&gt;
&lt;td style=&#34;text-align:left&#34;&gt;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 (&lt;code&gt;-w 0&lt;/code&gt;) for debug sessions.&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;-o&lt;/code&gt;&lt;br&gt;&lt;code&gt;--log-level&lt;/code&gt;&lt;/td&gt;
&lt;td style=&#34;text-align:left&#34;&gt;Override all specified logging-levels. This option is useful for debugging simulations. For example logging every possible event would be done with &lt;code&gt;-o TRACE&lt;/code&gt;.&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;-b&lt;/code&gt;&lt;br&gt;&lt;code&gt;--realtime-brake&lt;/code&gt;&lt;/td&gt;
&lt;td style=&#34;text-align:left&#34;&gt;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 &lt;code&gt;-b 1&lt;/code&gt; to execute the simulation in real time.&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;-r&lt;/code&gt;&lt;br&gt;&lt;code&gt;--random-seed&lt;/code&gt;&lt;/td&gt;
&lt;td style=&#34;text-align:left&#34;&gt;The global random seed to set for the simulation run. This is usually defined in the &lt;code&gt;scenario_config.json&lt;/code&gt;, but can be overridden using this option.&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;-v&lt;/code&gt;&lt;br&gt;&lt;code&gt;--start-visualizer&lt;/code&gt;&lt;/td&gt;
&lt;td style=&#34;text-align:left&#34;&gt;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
&lt;a href=&#34;https://staging.eclipse.org/mosaic/mosaic/docs/visualization/&#34;&gt;
Websocket Visualizer
&lt;/a&gt;
.&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td style=&#34;text-align:left&#34;&gt;&lt;code&gt;-h&lt;/code&gt;&lt;br&gt;&lt;code&gt;--help&lt;/code&gt;&lt;/td&gt;
&lt;td style=&#34;text-align:left&#34;&gt;Prints a help screen.&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;p&gt;While Eclipse MOSAIC is running, it prints some information on the command line:&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-shell&#34;&gt;[user@gnulinux mosaic]$ ./mosaic.sh -s HelloWorld
2020-09-08 16:46:09,794 INFO ROOT - Running Eclipse MOSAIC 21.0 on Java JRE v1.8.0_202 (AdoptOpenJdk)
2020-09-08 16:46:09,941 INFO FederationManagement - Start federation with id &#39;HelloWorld&#39;
2020-09-08 16:46:09,943 INFO FederationManagement - Add ambassador/federate with id &#39;application&#39;
2020-09-08 16:46:09,944 INFO FederationManagement - Add ambassador/federate with id &#39;mapping&#39;
2020-09-08 16:46:09,945 INFO FederationManagement - Add ambassador/federate with id &#39;sumo&#39;
2020-09-08 16:46:09,946 INFO FederationManagement - Deploying federate &#39;sumo&#39; locally in .\tmp\sumo
2020-09-08 16:46:09,962 INFO FederationManagement - Starting federate &#39;sumo&#39; locally in .\tmp\sumo
16:46:17 - Simulating: 195000000000ns (195.0s / 1000.0s) - 19.5% (RTF:33.10, ETC:25.2s)
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;The current simulation progress is shown in the following format.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;current wall clock time&lt;/li&gt;
&lt;li&gt;current simulation time in [ns] and [s]&lt;/li&gt;
&lt;li&gt;progress in %&lt;/li&gt;
&lt;li&gt;Real Time Factor (RTF) and Estimated Time to Completion (ETC)&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;h2 id=&#34;gather-results&#34;&gt;Gather results&lt;/h2&gt;
&lt;p&gt;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 &lt;code&gt;&amp;lt;mosaic-root&amp;gt;/logs/log-&amp;lt;timestamp&amp;gt;&lt;/code&gt; directory.&lt;/p&gt;
&lt;p&gt;Moreover, Eclipse MOSAIC offers uniformly formatted and visually prepared results using various
&lt;strong&gt;
&lt;a href=&#34;https://staging.eclipse.org/mosaic/mosaic/docs/visualization/&#34;&gt;
Output Generator
&lt;/a&gt;
&lt;/strong&gt; implementations. For example, the &lt;code&gt;FileOutputGenerator&lt;/code&gt; 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.&lt;/p&gt;
&lt;h2 id=&#34;scenario-configuration&#34;&gt;Scenario Configuration&lt;/h2&gt;
&lt;p&gt;The configuration of a simulation scenario consists of a detailed description for each coupled simulator. The main configuration file is found under &lt;code&gt;scenario_config.json&lt;/code&gt;,
which defines the list of coupled simulators:&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;{
&amp;quot;simulation&amp;quot;: {
&amp;quot;id&amp;quot;: &amp;quot;Barnim&amp;quot;,
&amp;quot;duration&amp;quot;: &amp;quot;1000s&amp;quot;,
&amp;quot;randomSeed&amp;quot;: 268965854,
&amp;quot;projection&amp;quot;: {
&amp;quot;centerCoordinates&amp;quot;: {
&amp;quot;latitude&amp;quot;: 52.511289,
&amp;quot;longitude&amp;quot;: 13.3167457
},
&amp;quot;cartesianOffset&amp;quot;: {
&amp;quot;x&amp;quot;: -385769.05,
&amp;quot;y&amp;quot;: -5819239.29
}
}
},
&amp;quot;federates&amp;quot;: {
&amp;quot;application&amp;quot;: true,
&amp;quot;environment&amp;quot;: false,
&amp;quot;cell&amp;quot;: false,
&amp;quot;ns3&amp;quot;: false,
&amp;quot;omnetpp&amp;quot;: false,
&amp;quot;sns&amp;quot;: false,
&amp;quot;sumo&amp;quot;: true,
&amp;quot;output&amp;quot;: true
}
}
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;This way, simulators can be easily added or removed from the simulation. Each of the coupled simulators is configured in the directory
of the &lt;code&gt;scenario_config.json&lt;/code&gt; file. The release bundle comes with a set of tutorial scenarios, which are described in detail
in the
&lt;a href=&#34;https://staging.eclipse.org/mosaic/mosaic/tutorials/&#34;&gt;
Tutorials section
&lt;/a&gt;
.&lt;/p&gt;
</description>
</item>
<item>
<title>Scenario Convert</title>
<link>https://staging.eclipse.org/mosaic/docs/building_scenarios/scenario_convert/</link>
<pubDate>Sun, 05 May 2019 00:00:00 +0100</pubDate>
<guid>https://staging.eclipse.org/mosaic/docs/building_scenarios/scenario_convert/</guid>
<description>&lt;div class=&#34;alert alert-extended&#34;&gt;
&lt;span class=&#34;extended-icon&#34; style=&#34;background-image: url(/mosaic/img/alert-extended.svg)&#34;&gt;&lt;/span&gt;
&lt;div&gt;
&lt;p&gt;The tool &lt;strong&gt;scenario-convert&lt;/strong&gt; is part of &lt;strong&gt;
&lt;a href=&#34;https://staging.eclipse.org/mosaic/mosaic/download/#overview&#34;&gt;
MOSAIC Extended
&lt;/a&gt;
&lt;/strong&gt;.&lt;/p&gt;
&lt;p&gt;However, you can use scenario-convert &lt;strong&gt;for free&lt;/strong&gt; to generate scenarios which are executable with Eclipse MOSAIC. &lt;strong&gt;
&lt;a href=&#34;https://www.dcaiti.tu-berlin.de/research/simulation/download/&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;
Get it here
&lt;/a&gt;
.&lt;/strong&gt;&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;div style=&#34;text-align: center;&#34;&gt;
&lt;a class=&#34;mosaic-btn mosaic-btn-primary&#34; href=&#34;https://www.dcaiti.tu-berlin.de/research/simulation/download/&#34; title=&#34;Download scenario-convert from DCAITI mirror&#34;&gt;&lt;i class=&#34;fas fa-download&#34;&gt;&lt;/i&gt;Download scenario-convert from DCAITI mirror&lt;/a&gt;
&lt;/div&gt;
&lt;p&gt;&lt;strong&gt;scenario-convert&lt;/strong&gt; 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.&lt;br&gt;
It will create a database, which is the basis for all map-related tasks performed by Eclipse MOSAIC (e.g. navigation,
route calculation&amp;hellip;).&lt;br&gt;
Based on a MOSAIC database, scenario-convert can export the data to SUMO-conform formats.
Furthermore one can choose, whether to use routes generated by &lt;code&gt;scenario-convert&lt;/code&gt;, use existing
routes or build own routes via route generation tools (e.g. DUAROUTER by SUMO).&lt;/p&gt;
&lt;p&gt;This chapter intends to highlight the most common workflows for the work with &lt;code&gt;scenario-convert&lt;/code&gt;.
We will be using
&lt;a href=&#34;https://staging.eclipse.org/mosaic/mosaic/docs/building_scenarios/files/steglitz.osm&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;
steglitz.osm
&lt;/a&gt;
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 &lt;code&gt;scenario-convert&lt;/code&gt;-script functions.&lt;/p&gt;
&lt;div class=&#34;alert alert-note&#34;&gt;
&lt;div&gt;
&lt;p&gt;
&lt;a href=&#34;#reference-documentation-for-scenario-convert&#34;&gt;
Here
&lt;/a&gt;
you can find a complete reference to all options scenario-convert offers.&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;figure id=&#34;figure-osm-file-of-steglitz&#34;&gt;
&lt;a data-fancybox=&#34;&#34; href=&#34;../images/osm_uncleaned.png&#34; data-caption=&#34;OSM-File of Steglitz&#34;&gt;
&lt;img src=&#34;../images/osm_uncleaned.png&#34; alt=&#34;&#34; &gt;
&lt;/a&gt;
&lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
OSM-File of Steglitz
&lt;/figcaption&gt;
&lt;/figure&gt;
&lt;h2 id=&#34;creating-a-complete-eclipse-mosaic-scenario-from-an-osm-file-with-one-command&#34;&gt;Creating a complete Eclipse MOSAIC-scenario from an OSM-file with one command&lt;/h2&gt;
&lt;p&gt;This is the most straight forward way to create a scenario from your OSM-file.
We will use the option &lt;code&gt;--osm2mosaic&lt;/code&gt;, which is a combination of the options &lt;code&gt;--osm2db&lt;/code&gt;
and &lt;code&gt;--db2mosaic&lt;/code&gt;.&lt;br&gt;
Let&amp;rsquo;s start off by showing you how a complete call could look like:&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;java -jar scenario-convert.jar --osm2mosaic -i steglitz.osm
&lt;/code&gt;&lt;/pre&gt;
&lt;div class=&#34;alert alert-note&#34;&gt;
&lt;div&gt;
&lt;p&gt;In this section we use the scenario name &lt;code&gt;steglitz.*&lt;/code&gt; as synonym for &lt;code&gt;path/to/steglitz.*&lt;/code&gt;.&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;p&gt;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:&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-plaintext&#34;&gt;└─ &amp;lt;working-directory&amp;gt;
└─ 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
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Let&amp;rsquo;s walk through all these files:&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;First the &lt;code&gt;steglitz.db&lt;/code&gt; will be created using the &lt;code&gt;steglitz.osm&lt;/code&gt;-file.&lt;/li&gt;
&lt;li&gt;The &lt;code&gt;steglitz.db&lt;/code&gt; will be used to create &lt;code&gt;steglitz.con.xml&lt;/code&gt;, &lt;code&gt;steglitz.edg.xml&lt;/code&gt; and &lt;code&gt;steglitz.nod.xml&lt;/code&gt;, which are files used by SUMO.&lt;/li&gt;
&lt;li&gt;
&lt;a href=&#34;https://sumo.dlr.de/wiki/NETCONVERT&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;
SUMO Netconvert
&lt;/a&gt;
is used to create &lt;code&gt;steglitz.net.xml&lt;/code&gt;, which is a
&lt;a href=&#34;https://sumo.dlr.de/wiki/Networks/SUMO_Road_Networks&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;
network representation
&lt;/a&gt;
in SUMO.&lt;/li&gt;
&lt;li&gt;Now the SUMO-configuration &lt;code&gt;steglitz.sumo.cfg&lt;/code&gt; is written.&lt;/li&gt;
&lt;li&gt;Afterwards the &lt;code&gt;mapping_config.json&lt;/code&gt; and &lt;code&gt;scenario_config.json&lt;/code&gt; are created and all files are moved to the right place.
In the &lt;code&gt;scenario_config.json&lt;/code&gt; values like the center coordinate will automatically be set using data from the SUMO related files.&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Clean the OSM-file using Osmosis&lt;/strong&gt;&lt;br&gt;
Osmosis will automatically be used to create a new OSM-file with the suffix &lt;code&gt;_cleaned&lt;/code&gt;. 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.&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;java -jar scenario-convert.jar --osm2mosaic -i steglitz.osm
&lt;/code&gt;&lt;/pre&gt;
&lt;div class=&#34;row&#34;&gt;
&lt;div class=&#34;col-6&#34;&gt;
&lt;figure id=&#34;figure-uncleaned-osm-file&#34;&gt;
&lt;a data-fancybox=&#34;&#34; href=&#34;../images/osm_uncleaned.png&#34; data-caption=&#34;Uncleaned OSM-file&#34;&gt;
&lt;img src=&#34;../images/osm_uncleaned.png&#34; alt=&#34;&#34; &gt;
&lt;/a&gt;
&lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
Uncleaned OSM-file
&lt;/figcaption&gt;
&lt;/figure&gt;
&lt;/div&gt;
&lt;div class=&#34;col-6&#34;&gt;
&lt;figure id=&#34;figure-cleaned-osm-file&#34;&gt;
&lt;a data-fancybox=&#34;&#34; href=&#34;../images/osm_cleaned.png&#34; data-caption=&#34;Cleaned OSM-file&#34;&gt;
&lt;img src=&#34;../images/osm_cleaned.png&#34; alt=&#34;&#34; &gt;
&lt;/a&gt;
&lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
Cleaned OSM-file
&lt;/figcaption&gt;
&lt;/figure&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;div class=&#34;row&#34;&gt;
&lt;div class=&#34;col-6&#34;&gt;
&lt;figure id=&#34;figure-uncleaned-net-file&#34;&gt;
&lt;a data-fancybox=&#34;&#34; href=&#34;../images/netfile_uncleaned.png&#34; data-caption=&#34;Uncleaned Net-file&#34;&gt;
&lt;img src=&#34;../images/netfile_uncleaned.png&#34; alt=&#34;&#34; &gt;
&lt;/a&gt;
&lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
Uncleaned Net-file
&lt;/figcaption&gt;
&lt;/figure&gt;
&lt;/div&gt;
&lt;div class=&#34;col-6&#34;&gt;
&lt;figure id=&#34;figure-cleaned-net-file&#34;&gt;
&lt;a data-fancybox=&#34;&#34; href=&#34;../images/netfile_cleaned.png&#34; data-caption=&#34;Cleaned Net-file&#34;&gt;
&lt;img src=&#34;../images/netfile_cleaned.png&#34; alt=&#34;&#34; &gt;
&lt;/a&gt;
&lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
Cleaned Net-file
&lt;/figcaption&gt;
&lt;/figure&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;p&gt;To avoid &amp;ldquo;cleaning&amp;rdquo; the OSM-file, please use the option &amp;ldquo;skip-osm-filter&amp;rdquo;.&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;java -jar scenario-convert.jar --osm2mosaic -i steglitz.osm --skip-osm-filter
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;&lt;strong&gt;Generating Routes&lt;/strong&gt;&lt;br&gt;
The scenario-convert also offers the option &lt;code&gt;--generate-routes&lt;/code&gt;, which will generate
a route-file, given some additional information. For example purposes we will run the
following command:&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;java -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
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;This will calculate three routes between the two given coordinates.&lt;/p&gt;
&lt;p&gt;Alternatively you can use the following command in order to generate routes with node-id&amp;rsquo;s as start and end point, which can be found in the &lt;code&gt;steglitz.nod.xml&lt;/code&gt; file.&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;java -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
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;See
&lt;a href=&#34;#reference-documentation-for-scenario-convert&#34;&gt;
below
&lt;/a&gt;
for all command line options.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Conlusion&lt;/strong&gt;&lt;br&gt;
This wraps up one of the main workflows with the scenario-convert-script.
A quick reminder on what we achieved:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Cleaned up an OSM-file to only contain relevant data.&lt;/li&gt;
&lt;li&gt;Converted that OSM-file to formats that Eclipse MOSAIC/SUMO can handle.&lt;/li&gt;
&lt;li&gt;Created the project structure for a scenario.&lt;/li&gt;
&lt;li&gt;Calculated routes between two coordinates.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;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
&lt;a href=&#34;https://staging.eclipse.org/mosaic/mosaic/docs/building_scenarios/&#34;&gt;
here (Simulation Scenarios)
&lt;/a&gt;
and
&lt;a href=&#34;https://staging.eclipse.org/mosaic/mosaic/docs/develop_applications/&#34;&gt;
here (Application Development)
&lt;/a&gt;
.&lt;br&gt;
While this is the &amp;lsquo;happy world&amp;rsquo; 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.&lt;/p&gt;
&lt;h2 id=&#34;importing-routes-to-your-scenario&#34;&gt;Importing Routes to your scenario&lt;/h2&gt;
&lt;p&gt;As mentioned above your routes won&amp;rsquo;t always be created by the scenario-convert script. We generated some routes
for the steglitz-scenario using SUMO&amp;rsquo;s
&lt;a href=&#34;http://sumo.dlr.de/wiki/DUAROUTER&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;
duarouter
&lt;/a&gt;
, which you can find
&lt;a href=&#34;https://staging.eclipse.org/mosaic/mosaic/docs/building_scenarios/files/steglitz.rou.xml&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;
here
&lt;/a&gt;
. We&amp;rsquo;ll start with only the &lt;code&gt;steglitz.osm&lt;/code&gt; and
&lt;code&gt;steglitz.rou.xml&lt;/code&gt; files:&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-plaintext&#34;&gt;└─ &amp;lt;working-directory&amp;gt;
├─ steglitz.osm
└─ steglitz.rou.xml
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;&lt;strong&gt;Creating the database&lt;/strong&gt;&lt;br&gt;
We&amp;rsquo;ll start off by solely creating the database and applying OSMOSIS with the following command:&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;java -jar scenario-convert.jar --osm2db -i steglitz.osm
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;The directory should look like this:&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-plaintext&#34;&gt;└─ &amp;lt;working-directory&amp;gt;
├─ steglitz.db
├─ steglitz.osm
├─ steglitz.rou.xml
└─ steglitz_cleaned.osm
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;&lt;strong&gt;Importing the route-file&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;Let&amp;rsquo;s import our routes into the database.&lt;br&gt;
We achieve this by calling:&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;java -jar scenario-convert.jar --sumo2db -i steglitz.rou.xml -d .\steglitz.db
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Now all new routes are imported into our database. The following image shows a visualization of one of
the created routes.&lt;/p&gt;
&lt;figure id=&#34;figure-visualization-of-one-of-the-routes&#34;&gt;
&lt;a data-fancybox=&#34;&#34; href=&#34;../images/steglitz_route.png&#34; data-caption=&#34;Visualization of one of the routes&#34;&gt;
&lt;img src=&#34;../images/steglitz_route.png&#34; alt=&#34;&#34; &gt;
&lt;/a&gt;
&lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
Visualization of one of the routes
&lt;/figcaption&gt;
&lt;/figure&gt;
&lt;p&gt;&lt;strong&gt;Creating the scenario&lt;/strong&gt;&lt;br&gt;
The final step is to create the scenario from the files we created so far.&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;java -jar scenario-convert.jar --db2mosaic -d .\steglitz.db
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Instead of copying our SUMO-files this will generate all necessary files and move them into a Eclipse MOSAIC-conform
folder structure:&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-plaintext&#34;&gt;└─ &amp;lt;working-directory&amp;gt;
├─ steglitz.osm
└─ steglitz
├─ application
| └─ steglitz.db
├─ mapping
| └─ mapping_config.json
├─ sumo
| ├─ steglitz.net.xml
| └─ steglitz.sumocfg
└─ scenario_config.json
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;As you can see the resulting folder structure looks just like the final output from the first workflow described.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Conclusion&lt;/strong&gt;&lt;br&gt;
You 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.&lt;/p&gt;
&lt;h3 id=&#34;attached-files&#34;&gt;Attached Files&lt;/h3&gt;
&lt;p&gt;A list of all attached files in this chapter:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;a href=&#34;https://staging.eclipse.org/mosaic/mosaic/docs/building_scenarios/files/steglitz.osm&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;
Steglitz OSM-file
&lt;/a&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;a href=&#34;https://staging.eclipse.org/mosaic/mosaic/docs/building_scenarios/files/steglitz.rou.xml&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;
Steglitz Route-file
&lt;/a&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id=&#34;reference-documentation-for-scenario-convert&#34;&gt;Reference documentation for scenario-convert&lt;/h2&gt;
&lt;h3 id=&#34;usage-of-scenario-convert&#34;&gt;Usage of scenario-convert&lt;/h3&gt;
&lt;p&gt;The following listing shows an overview for the usage of scenario-convert:&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;usage: scenario-convert [OPERATION] [OPTIONS]
Examples:
1. Import an osm file and write data into database
&amp;gt; scenario-convert --osm2db -i &amp;lt;OSMFILE&amp;gt; [-d &amp;lt;DATABASE&amp;gt;]
2. Export database content to SUMO-readable files
&amp;gt; scenario-convert --db2sumo -d &amp;lt;DATABASE&amp;gt; [-s &amp;lt;SUMOPREFIX&amp;gt;]
3. Import a SUMO routefile into a database
&amp;gt; scenario-convert --sumo2db -d &amp;lt;DATABASE&amp;gt; -i &amp;lt;ROUTEFILE&amp;gt;.rou.xml
4. Combine steps 1 and 2
&amp;gt; scenario-convert --osm2sumo -d &amp;lt;DATABASE&amp;gt; -i &amp;lt;OSMFILE&amp;gt; [-s &amp;lt;SUMOPREFIX&amp;gt;]
5. Export db content to Shapefile format
&amp;gt; scenario-convert --db2shp -d &amp;lt;DATABASE&amp;gt;
6. Import an srtm file and write elevation data to nodes of an existing database
&amp;gt; scenario-convert --srtm2db -i &amp;lt;SRTMFILE&amp;gt; -d &amp;lt;DATABASE&amp;gt;
7. Create a complete MOSAIC scenario from an osm file
&amp;gt; scenario-convert --osm2mosaic -i &amp;lt;OSMFILE&amp;gt;
8. Create a scenario database from an SUMO net file
&amp;gt; scenario-convert --sumo2db -i &amp;lt;NETFILE&amp;gt;.net.xml
9. Calculate a route from node 123 to node 456
&amp;gt; scenario-convert --generate-routes -d &amp;lt;DATABASE&amp;gt; --route-begin-node-id 123 --route-end-node-id 456
The following arguments are available:
-h,--help Prints this help screen.
-c,--config-file &amp;lt;PATH&amp;gt; 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 &amp;lt;PATH&amp;gt; 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 &amp;lt;PATH&amp;gt; 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 &amp;lt;STRING&amp;gt; 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 &amp;lt;PATH&amp;gt; Uses the given mapping configuration to export existing vehicleTypes and
vehicles data to *.rou.xml.
--import-lat &amp;lt;DOUBLE&amp;gt; Center latitude of imported region to project coordinates.
--import-lon &amp;lt;DOUBLE&amp;gt; Center longitude of imported region to project coordinates.
--import-zone &amp;lt;STRING&amp;gt; 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 &amp;lt;DOUBLE&amp;gt; Latitude of the starting point, needs --route-begin-lon as well.
--route-begin-lon &amp;lt;DOUBLE&amp;gt; Longitude of the starting point, needs --route-begin-lat as well.
--route-begin-latlon &amp;lt;DOUBLE,DOUBLE&amp;gt; [latitude],[longitude] of the starting point.
--route-begin-node-id &amp;lt;STRING&amp;gt; OSM node id of the starting point (use instead of lat/lon).
--route-end-lat &amp;lt;DOUBLE&amp;gt; Latitude of the starting point, needs --route-end-lon as well.
--route-end-lon &amp;lt;DOUBLE&amp;gt; Longitude of the starting point, needs --route-end-lat as well.
--route-end-latlon &amp;lt;DOUBLE,DOUBLE&amp;gt; [latitude],[longitude] of the ending point.
--route-end-node-id &amp;lt;STRING&amp;gt; OSM node id of the ending point (use instead of lat/lon).
--route-matrix &amp;lt;STRING,STRING,...&amp;gt; Calculates all possible routes starting and ending at the given nodes, given
as comma-separated list (e.g. 12345,87123,89123)
--number-of-routes &amp;lt;INTEGER&amp;gt; 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 MOSAIC 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 &amp;lt;PATH&amp;gt; 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).
&lt;/code&gt;&lt;/pre&gt;
&lt;h3 id=&#34;configuration-files-for-scenario-convert&#34;&gt;Configuration-files for scenario-convert&lt;/h3&gt;
&lt;p&gt;Scenario-convert offers a way to safe your conversion-parameters in a &lt;code&gt;JSON&lt;/code&gt; configuration file using
the option &lt;code&gt;-c&lt;/code&gt; or &lt;code&gt;--config-file&lt;/code&gt;.&lt;br&gt;
The following listing shows how to save the options used in the example above:&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;{
&amp;#34;operatingMode&amp;#34;: &amp;#34;osm2mosaic&amp;#34;,
&amp;#34;inputFile&amp;#34;: &amp;#34;steglitz.osm&amp;#34;,
&amp;#34;executeOsmosis&amp;#34;: true,
&amp;#34;generateRoutes&amp;#34;: true,
&amp;#34;routeBeginLatLon&amp;#34;: &amp;#34;52.457616,13.318392&amp;#34;,
&amp;#34;routeEndLatLon&amp;#34;: &amp;#34;52.454774,13.333554&amp;#34;,
&amp;#34;numberOfRoutes&amp;#34;: 3
}
&lt;/code&gt;&lt;/pre&gt;
&lt;h3 id=&#34;speed-files&#34;&gt;Speed-files&lt;/h3&gt;
&lt;p&gt;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 &lt;code&gt;--osm-speeds-file &amp;lt;FILE&amp;gt;&lt;/code&gt;. In the speed properties file, for each way type a speed value can
be defined, according to the OSM
&lt;a href=&#34;http://wiki.openstreetmap.org/wiki/Key:highway&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;
&lt;code&gt;highway&lt;/code&gt;
&lt;/a&gt;
key.&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;# 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 &amp;#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
&lt;/code&gt;&lt;/pre&gt;
</description>
</item>
<item>
<title>Simulation Results</title>
<link>https://staging.eclipse.org/mosaic/docs/getting_started/results/</link>
<pubDate>Sun, 05 May 2019 00:00:00 +0100</pubDate>
<guid>https://staging.eclipse.org/mosaic/docs/getting_started/results/</guid>
<description>&lt;p&gt;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 &lt;code&gt;&amp;lt;mosaic-root&amp;gt;/logs/log-&amp;lt;timestamp&amp;gt;&lt;/code&gt;. For each simulation run a new folder is created.&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-plaintext&#34;&gt;└─ log-&amp;lt;timestamp&amp;gt;
├─ apps
| └─ &amp;lt;unitType&amp;gt;_&amp;lt;unitId&amp;gt; ................. 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
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;In addition to standard logging output for each federate there is a &lt;code&gt;activities.csv&lt;/code&gt; 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 &lt;code&gt;activities&lt;/code&gt; has to be
set to &lt;code&gt;INFO&lt;/code&gt; in the &lt;code&gt;logback.xml&lt;/code&gt; (see section below).&lt;/p&gt;
&lt;h2 id=&#34;logging&#34;&gt;Logging&lt;/h2&gt;
&lt;p&gt;The main configuration file for logging is &lt;code&gt;&amp;lt;mosaic-root&amp;gt;/etc/logback.xml&lt;/code&gt;. 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&amp;rsquo;s internal interactions or traffic
simulation depending on your simulation focus.&lt;/p&gt;
&lt;p&gt;Eclipse MOSAIC uses &lt;em&gt;LOGback&lt;/em&gt; as logging framework. &lt;em&gt;LOGback&lt;/em&gt; offers a lot of parameters to adapt the output to your needs. Please refer to
&lt;a href=&#34;https://logback.qos.ch/manual/layouts.html#ClassicPatternLayout&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;
this site
&lt;/a&gt;
for a detailed overview of all
parameters you can use in the &lt;code&gt;logback.xml&lt;/code&gt; file.&lt;/p&gt;
&lt;p&gt;Please note that you can adjust the output to your needs by setting different log levels (&lt;code&gt;ERROR&lt;/code&gt;, &lt;code&gt;INFO&lt;/code&gt;,
&lt;code&gt;DEBUG&lt;/code&gt; etc.) for each component in the file at &lt;code&gt;&amp;lt;mosaic-root&amp;gt;/etc/logback.xml&lt;/code&gt;. This might also influence
the simulation performance because of a possibly high amount of data to be logged.&lt;/p&gt;
&lt;h3 id=&#34;federate-specific-logging&#34;&gt;Federate specific logging&lt;/h3&gt;
&lt;p&gt;Depending on the simulation purpose, further configuration possibilities for federate specific logging
may be of interest.&lt;/p&gt;
&lt;p&gt;For instance, OMNeT++ exhibits an elaborated logging concept. The &lt;code&gt;omnetpp.ini&lt;/code&gt; in the scenario folder
includes options to adjust the logging levels. The outputs of this federate are written to &lt;code&gt;CommunicationDetails.log&lt;/code&gt;.&lt;/p&gt;
</description>
</item>
<item>
<title>Simulator Coupling</title>
<link>https://staging.eclipse.org/mosaic/docs/extending_mosaic/simulator_coupling/</link>
<pubDate>Sun, 05 May 2019 00:00:00 +0100</pubDate>
<guid>https://staging.eclipse.org/mosaic/docs/extending_mosaic/simulator_coupling/</guid>
<description>&lt;p&gt;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).&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id=&#34;implementing-a-federate-ambassador&#34;&gt;Implementing a Federate Ambassador&lt;/h2&gt;
&lt;p&gt;In order to simplify federate development and to make the usage of the mechanisms provided by the RTI
safer, an abstract class called &lt;code&gt;AbstractFederateAmbassador&lt;/code&gt; is provided by the Eclipse MOSAIC core package.
It implements the &lt;code&gt;FederateAmbassador&lt;/code&gt; 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 &lt;code&gt;AbstractFederateAmbassador&lt;/code&gt; as a super class, it has to provide two information to the
superclass while constructing an instance of the class. These are:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;&lt;code&gt;isTimeConstrained&lt;/code&gt;: The general way this parameter can be understood, is that if it is set to &lt;strong&gt;true&lt;/strong&gt;
the federate is sensitive towards the time stamp order of interactions. The &lt;code&gt;AbstractFederateAmbassador&lt;/code&gt;
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 &lt;strong&gt;false&lt;/strong&gt;, incoming interactions will be forwarded immediately to
the federate, thus resulting in a &lt;em&gt;receive-order&lt;/em&gt; of interactions at the federate.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;code&gt;isTimeRegulating&lt;/code&gt;: 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 &lt;strong&gt;true&lt;/strong&gt;, the &lt;code&gt;AbstractFederateAmbassador&lt;/code&gt;
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 &lt;strong&gt;false&lt;/strong&gt;, 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.&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;figure id=&#34;figure-flowchart-of-interaction-handling&#34;&gt;
&lt;a data-fancybox=&#34;&#34; href=&#34;../images/flowchart_timeconstrained_timeregulating.png&#34; data-caption=&#34;Flowchart of Interaction handling&#34;&gt;
&lt;img src=&#34;../images/flowchart_timeconstrained_timeregulating.png&#34; alt=&#34;&#34; &gt;
&lt;/a&gt;
&lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
Flowchart of Interaction handling
&lt;/figcaption&gt;
&lt;/figure&gt;
&lt;h3 id=&#34;further-notes&#34;&gt;Further notes&lt;/h3&gt;
&lt;p&gt;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
&lt;a href=&#34;https://en.wikipedia.org/wiki/High_Level_Architecture&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;
here
&lt;/a&gt;
and at the linked references) you might notice, that the
previous flowchart does not completely reflect the proposed mechanisms. For instance, the &lt;code&gt;isTimeRegulating&lt;/code&gt; flag has no effect, when the
&lt;code&gt;isTimeConstrained&lt;/code&gt; flag is not set.&lt;br&gt;
So at some points you might stumble upon federates, which have their &lt;code&gt;isTimeConstrained&lt;/code&gt; and &lt;code&gt;isTimeRegulating&lt;/code&gt; flags set to different
values as you would expect. An example of this is the &lt;code&gt;ApplicationAmbassador&lt;/code&gt;. One would expect it to be time-constrained as well as
time-regulating. This isn&amp;rsquo;t the case though, because the &lt;code&gt;ApplicationAmbassador&lt;/code&gt; implements its own time- and event-management,
which would interfere with the internal mechanisms.&lt;br&gt;
When implementing your own federate, you can use the existing ones as reference.&lt;/p&gt;
&lt;h3 id=&#34;example&#34;&gt;Example&lt;/h3&gt;
&lt;p&gt;A federate that is &lt;code&gt;timeConstrained&lt;/code&gt; and &lt;code&gt;timeRegulated&lt;/code&gt; can handle a time stamped interaction
only after receiving a corresponding time advance grant. For that reason, the &lt;code&gt;AbstractFederateAmbassador&lt;/code&gt;
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 &lt;code&gt;processInteraction&lt;/code&gt;
method call and afterwards invokes &lt;code&gt;processTimeAdvanceGrant&lt;/code&gt; 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.&lt;/p&gt;
&lt;figure id=&#34;figure-sequence-diagram-illustrating-the-flow-of-information&#34;&gt;
&lt;a data-fancybox=&#34;&#34; href=&#34;../images/federate-sequence.jpeg&#34; data-caption=&#34;Sequence diagram illustrating the flow of information.&#34;&gt;
&lt;img src=&#34;../images/federate-sequence.jpeg&#34; alt=&#34;&#34; &gt;
&lt;/a&gt;
&lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
Sequence diagram illustrating the flow of information.
&lt;/figcaption&gt;
&lt;/figure&gt;
&lt;h3 id=&#34;integration-into-eclipse-mosaic&#34;&gt;Integration into Eclipse MOSAIC&lt;/h3&gt;
&lt;p&gt;The first step to integrate a new component is the extension of the configuration file &lt;code&gt;etc/runtime.json&lt;/code&gt;.
An example for a federate configuration can be found in following listing.&lt;/p&gt;
&lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;&amp;quot;federates&amp;quot;: [
...
{
&amp;quot;id&amp;quot;: &amp;quot;omnetpp&amp;quot;,
&amp;quot;classname&amp;quot;: &amp;quot;org.eclipse.mosaic.fed.omnetpp.ambassador.OmnetppAmbassador&amp;quot;,
&amp;quot;configuration&amp;quot;: &amp;quot;omnetpp_config.json&amp;quot;,
&amp;quot;configurationDeployPath&amp;quot;: &amp;quot;omnetpp-federate/simulations&amp;quot;,
&amp;quot;priority&amp;quot;: 50,
&amp;quot;dockerImage&amp;quot;: &amp;quot;&amp;quot;,
&amp;quot;host&amp;quot;: &amp;quot;local&amp;quot;,
&amp;quot;port&amp;quot;: 4998,
&amp;quot;deploy&amp;quot;: true,
&amp;quot;start&amp;quot;: true,
&amp;quot;subscriptions&amp;quot;: [
&amp;quot;VehicleRegistration&amp;quot;,
&amp;quot;RsuRegistration&amp;quot;,
&amp;quot;TrafficLightRegistration&amp;quot;,
...
],
&amp;quot;javaClasspathEntries&amp;quot;: []
},
...
]
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;The following parameters are available:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;&lt;code&gt;class&lt;/code&gt; - Attribute giving the full qualified name of the Java class which implements the Feder-
ateAmbassador interface.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;code&gt;id&lt;/code&gt; - 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.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;code&gt;deploy&lt;/code&gt; - If set to true, the federate placed under bin/fed/&lt;id&gt; will be copied to the execution
host (according to the host configuration file).&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;code&gt;start&lt;/code&gt; - 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.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;code&gt;subscriptions&lt;/code&gt; - 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.&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;hr&gt;
&lt;h2 id=&#34;interaction-extension&#34;&gt;Interaction extension&lt;/h2&gt;
&lt;p&gt;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 &lt;code&gt;Interaction&lt;/code&gt;, 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 &lt;code&gt;Interaction&lt;/code&gt; offers these attributes but no further content. The exchanged content has to be
implemented by extending the class &lt;code&gt;Interaction&lt;/code&gt;. The already implemented extensions cover the content
necessary to simulate common scenarios. However, for further scenarios further interactions might be
required.&lt;/p&gt;
&lt;figure id=&#34;figure-interaction-classes-and-their-relationships&#34;&gt;
&lt;a data-fancybox=&#34;&#34; href=&#34;../images/mosaic-message-classes.png&#34; data-caption=&#34;Interaction classes and their relationships..&#34;&gt;
&lt;img src=&#34;../images/mosaic-message-classes.png&#34; alt=&#34;&#34; &gt;
&lt;/a&gt;
&lt;figcaption data-pre=&#34;Figure &#34; data-post=&#34;:&#34; class=&#34;numbered&#34;&gt;
Interaction classes and their relationships..
&lt;/figcaption&gt;
&lt;/figure&gt;
</description>
</item>
<item>
<title></title>
<link>https://staging.eclipse.org/mosaic/group/dcaiti/</link>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://staging.eclipse.org/mosaic/group/dcaiti/</guid>
<description></description>
</item>
<item>
<title>Eclipse SUMO - Simulation of Urban MObility</title>
<link>https://staging.eclipse.org/mosaic/docs/simulators/traffic_simulator_sumo/</link>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://staging.eclipse.org/mosaic/docs/simulators/traffic_simulator_sumo/</guid>
<description>&lt;p&gt;&lt;strong&gt;Eclipse SUMO&lt;/strong&gt; is a 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.&lt;/p&gt;
&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;&lt;/th&gt;
&lt;th&gt;&lt;/th&gt;
&lt;th&gt;&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;Operating System&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;GNU/Linux and Microsoft Windows&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;License&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;EPL-2.0&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;Website&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;
&lt;a href=&#34;https://www.eclipse.org/sumo/&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;
https://www.eclipse.org/sumo/
&lt;/a&gt;
&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;Supported versions&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;Recommended version:&lt;br&gt;Full support:&lt;br&gt;Limited support:&lt;/td&gt;
&lt;td&gt;1.8.0&lt;br&gt;1.2.0 - 1.8.0&lt;br&gt;1.0.1, 1.1.0&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;h3 id=&#34;installation&#34;&gt;Installation&lt;/h3&gt;
&lt;a class=&#34;mosaic-btn mosaic-btn-primary&#34; href=&#34;https://sumo.dlr.de/wiki/Downloads&#34; title=&#34;Download Eclipse SUMO&#34;&gt;&lt;i class=&#34;fas fa-external-link-alt&#34;&gt;&lt;/i&gt;Download Eclipse SUMO&lt;/a&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;div class=&#34;alert alert-note&#34;&gt;
&lt;div&gt;
&lt;p&gt;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
&lt;code&gt;PATH&lt;/code&gt; environment variable. Alternatively, the environment variable &lt;code&gt;SUMO_HOME&lt;/code&gt; can be used to
define the installation directory of SUMO.&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;div class=&#34;alert alert-tip&#34;&gt;
&lt;div&gt;
&lt;p&gt;We recommend using the 64 bit version of SUMO if you want to simulate scenarios with large traffic networks.&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;h3 id=&#34;configuration&#34;&gt;Configuration&lt;/h3&gt;
&lt;p&gt;This ambassador can be configured with a configuration file. The specific path is &lt;code&gt;&amp;lt;scenarioName&amp;gt;/sumo/sumo_config.json&lt;/code&gt;.
If no such file exists, the following default configuration options are used:&lt;/p&gt;
&lt;pre