Google Git
Sign in
eclipse / gerrit / www.eclipse.org / mosaic / 96d8c137f6b6b7deca26fe3d794a05ec6b73340c / . / docs / develop_applications / index.xml
blob: 3ba0c9a9f210c7d3e4eb97730be950862536bc3b [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>Basics in Application Development | Eclipse MOSAIC</title>
<link>https://www.eclipse.org/mosaic/docs/develop_applications/</link>
<atom:link href="https://www.eclipse.org/mosaic/docs/develop_applications/index.xml" rel="self" type="application/rss+xml" />
<description>Basics in Application Development</description>
<generator>Source Themes Academic (https://sourcethemes.com/academic/)</generator><language>en-us</language><lastBuildDate>Tue, 06 Aug 2019 00:00:00 +0000</lastBuildDate>
<image>
<url>https://www.eclipse.org/mosaic/images/logo.svg</url>
<title>Basics in Application Development</title>
<link>https://www.eclipse.org/mosaic/docs/develop_applications/</link>
</image>
<item>
<title>Communication in Applications</title>
<link>https://www.eclipse.org/mosaic/docs/develop_applications/communication/</link>
<pubDate>Sun, 05 May 2019 00:00:00 +0100</pubDate>
<guid>https://www.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://www.eclipse.org/mosaic/docs/simulators/network_simulator_omnetpp&#34;&gt;OMNeT++&lt;/a&gt;,
&lt;a href=&#34;https://www.eclipse.org/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://www.eclipse.org/mosaic/docs/simulators/network_simulator_sns&#34;&gt;SNS&lt;/a&gt;
or
&lt;a href=&#34;https://www.eclipse.org/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;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://www.eclipse.org/mosaic/docs/simulators/network_simulator_omnetpp&#34;&gt;OMNeT++&lt;/a&gt;, &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/simulators/network_simulator_ns3&#34;&gt;ns-3&lt;/a&gt;). But the
built in communication simulator &lt;a href=&#34;https://www.eclipse.org/mosaic/docs/simulators/network_simulator_sns&#34;&gt;SNS&lt;/a&gt; includes a simple routing protocol “Flooding”.&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 of all, 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://www.eclipse.org/mosaic/docs/develop_applications/event_scheduler/</link>
<pubDate>Sun, 11 Aug 2019 00:00:00 +0000</pubDate>
<guid>https://www.eclipse.org/mosaic/docs/develop_applications/event_scheduler/</guid>
<description>&lt;p&gt;The different modules of the
&lt;a href=&#34;https://www.eclipse.org/mosaic/docs/simulators/application_simulator/#eclipse-mosaic-application-simulator&#34;&gt;Eclipse MOSAIC 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://www.eclipse.org/mosaic/docs/develop_applications/road_traffic/</link>
<pubDate>Tue, 06 Aug 2019 00:00:00 +0000</pubDate>
<guid>https://www.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://www.eclipse.org/mosaic/docs/simulators/application_simulator/&#34;&gt;Eclipse MOSAIC 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 applicationNT 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; &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; &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;
&lt;p&gt;Some components of Eclipse MOSAIC need to identify further parts of the road network, such as one edge between two nodes, or one specific lane of one edge. Therefore, the following objects are identified as following:&lt;/p&gt;
&lt;p&gt;&lt;code&gt;Edges&lt;/code&gt; are described by one start and one end node. The identifier of an edge consists of two parts (using the string pattern &lt;code&gt;aaa_bbb_ccc_ddd&lt;/code&gt;):&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;code&gt;aaa_bbb_ccc&lt;/code&gt; - ID the connection the edge belongs to.&lt;/li&gt;
&lt;li&gt;&lt;code&gt;ddd&lt;/code&gt; - ID of the node the edge starts at.&lt;/li&gt;
&lt;/ul&gt;
&lt;figure id=&#34;figure-structure-of-the-edge-id&#34;&gt;
&lt;a data-fancybox=&#34;&#34; href=&#34;../images/edges.jpeg&#34; data-caption=&#34;Structure of the Edge-ID&#34;&gt;
&lt;img src=&#34;../images/edges.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;
Structure of the Edge-ID
&lt;/figcaption&gt;
&lt;/figure&gt;
&lt;p&gt;&lt;code&gt;Lanes&lt;/code&gt; are described by an edge and a lane index. The identifier of a lane consists of two parts (using the string pattern &lt;code&gt;aaa_bbb_ccc_ddd_e&lt;/code&gt;):&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;code&gt;aaa_bbb_ccc_ddd&lt;/code&gt; - ID the edge the lane belongs to.&lt;/li&gt;
&lt;li&gt;&lt;code&gt;e&lt;/code&gt; - Index of the lane, starting by 0 (leftmost lane).&lt;/li&gt;
&lt;/ul&gt;
&lt;figure id=&#34;figure-structure-of-the-lane-id&#34;&gt;
&lt;a data-fancybox=&#34;&#34; href=&#34;../images/lanes.jpeg&#34; data-caption=&#34;Structure of the Lane-ID&#34;&gt;
&lt;img src=&#34;../images/lanes.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;
Structure of the Lane-ID
&lt;/figcaption&gt;
&lt;/figure&gt;
</description>
</item>
</channel>
</rss>