diff --git a/config/_default/menus.toml b/config/_default/menus.toml index 28c02d54..37f40ad0 100644 --- a/config/_default/menus.toml +++ b/config/_default/menus.toml @@ -25,20 +25,24 @@ name = "Tutorials" url = "/tutorials/" weight = 40 +[[main]] + name = "Workshops" + url = "/workshops/" + weight = 50 [[main]] identifier = "Download" name = "Download" url = "/download/" - weight = 50 + weight = 60 [[main]] identifier = "Commercial" name = "Commercial" url = "/commercial/" - weight = 60 + weight = 70 [[main]] name = "Community" url = "/community/" - weight = 70 + weight = 80 [[footer]] @@ -63,24 +67,30 @@ identifier = "tutorials" parent = "mosaic" weight = 3 + [[footer]] + name = "Workshops" + url = "/workshops/" + identifier = "workshops" + parent = "mosaic" + weight = 4 [[footer]] name = "License" url = "/about/#license" identifier = "license" parent = "mosaic" - weight = 4 + weight = 5 [[footer]] name = "Projects" url = "/community/#projects" identifier = "projects" parent = "mosaic" - weight = 5 + weight = 6 [[footer]] name = "Publications" url = "/publications/" identifier = "publications" parent = "mosaic" - weight = 6 + weight = 7 [[footer]] name = "Community" identifier = "community" @@ -332,3 +342,33 @@ """ +[[workshops]] + name = "MOSAIC 101: Modelling Mobility" + identifier = "maintenance_car" + url = "/workshops/maintenance_car/" + weight = 1 + post = """ + +

You will learn to model a mobility use-case. This workshop will teach you:

+ + """ + +[[workshops]] +name = "Future Workshops" +identifier = "future" +weight = 100 +post = """ + +

More Workshops Coming Soon:

+ + """ \ No newline at end of file diff --git a/content/docs/develop_applications/communication-ad-hoc.md b/content/docs/develop_applications/communication-ad-hoc.md new file mode 100644 index 00000000..4483088c --- /dev/null +++ b/content/docs/develop_applications/communication-ad-hoc.md @@ -0,0 +1,233 @@ +--- +title: Ad-Hoc Communication in Applications +linktitle: Communication - Ad-Hoc +toc: true +type: docs +date: "2024-11-20T00:00:00+01:00" +draft: false +weight: 50 +menu: + docs: + parent: develop_applications + weight: 50 +--- + +Eclipse MOSAIC has different classes, which allow you to define the network type and the specific area where the +communication should occur. Ad-Hoc communication can be achieved with external network simulators ([OMNeT++](/docs/simulators/network_simulator_omnetpp), +[ns-3](/docs/simulators/network_simulator_ns3)) or the built-in communication simulator [SNS](/docs/simulators/network_simulator_sns). + +Depending on the needs of the application, there are different approaches to solve the communication issue in Eclipse MOSAIC +simulations. It is possible to modify the selected communication mode dependent on requirements. + +Generally, the following modes are available for ad-hoc communication: + + * Geographically-scoped broadcast + * Geographically-scoped unicast + * Topologically-scoped broadcast + * Topologically-scoped unicast + +## General Configuration +The first step to enable your application to use communication capabilities, is to make sure it extends the `AbstractApplication`-class +with an `OperatingSystem` which provides an Ad-Hoc module, such as `VehicleOperatingSystem`or `RoadSideUnitOperatingSystem`. +Additionally, if you want your application to act upon the reception or transmission of messages, make sure it implements the interface +`CommunicationApplication`. +Afterward, you can enable the ad-hoc communication module by following the instruction in [Ad-hoc Configuration](#ad-hoc-configuration). + +This example showcases the inheritance of an application class that can transmit and receive messages via Ad-Hoc communication, once you have +enabled the module. +```java +public class AdHocApplication extends AbstractApplication implements CommunicationApplication {} +``` +--- + +## Ad-hoc Communication + +The Ad-hoc network does not rely on a pre-existing infrastructure. Provided that vehicles are equipped with Ad-hoc +modules, they are able to communicate with each other dynamically. In case of a sufficient number of Ad-hoc equipped +vehicles, a message can be transferred via hops quickly over a long distance. + +### Ad-hoc Configuration +Make sure you set up your application as described in [General Configuration](#general-configuration). +Afterward, to configure and enable the AdHoc-module in your application you have to call the `enable`-method of your applications' +Ad-hoc module and define a configuration. +Usually you will do this in the `onStartup()`-method to enable the module from the get-go. +Below is an example configuration taken from the Tiergarten-tutorial. Instead of configuring the `.power(...)[mW]` +it is also possible to configure a `.distance(...)[m]`. +```java +@Override +public void onStartup() { + getOs().getAdHocModule().enable(new AdHocModuleConfiguration() + .addRadio() + .channel(AdHocChannel.CCH) + .power(50) + .create()); + } +``` + +## Ad-hoc Routing Modes +There are several different routing modes for ad-hoc communication, that differ in the route finding and number of receiving entities. +The following is an introduction into the most commonly used modes and how to use them within Eclipse MOSAIC. + +### Ad-hoc Topologically-Scoped Broadcast + +In the topologically-scoped broadcast mode, communication between vehicles takes place regardless of the geographic conditions. +However, in theory the communicating entities must be operated on the same Ad-hoc channel. Remember, that the +[SNS](/docs/simulators/network_simulator_sns) does not implement channels. + +The most common use of an ad-hoc broadcast is to only reach the neighbors of the sending node. In this cast, it is necessary to explicitly +set the number of hops to one. This indicates, that the lifespan of the message is one and is not sent further, once it has been received. +To use the singlehop approach, Eclipse MOSAIC allows to use the method +`.singlehop()` in the `AdHocMessageRoutingBuilder`. This sets the number of hops a message can take, aka. the time to live (TTL) of the +message, to one. + +Below is a configuration example that sends a topologically-scoped singlehop broadcast over the default channel. + +```java +MessageRouting routing = getOs().getAdHocModule().createMessageRouting() + .singlehop() + .broadcast() + .topological() + .build(); + +getOs().getAdHocModule().sendV2XMessage(new MyV2XMessage(routing)); +``` + +The following figure shows a simplified model based on the singlehop principle. The *veh_1* sends messages to all +simulation entities(***RSU***, ***veh_2***) that are using the same ad-hoc channel. After transmission, the message can +no longer be forwarded by the receiver. + +{{< figure src="../images/ad-hoc-topologically-scoped-broadcast.png" +title="Topologically-scoped singlehop broadcast" numbered="true" >}} + +### Ad-hoc Topologically-Scoped Unicast + +Unlike with the topologically-scoped broadcast, the communication in topologically-scoped unicast mode will be addressed explicitly to +the recipient. The addressing can be done either through receiver name (vehicle-ID e.g. "veh_0") or the IP-Address of the vehicle. + +```java +final byte[] ipv4Address = {127,36,50,4}; + +int hops = 2; + +MessageRouting routing = getOs().getAdHocModule().createMessageRouting() + .hops(hops) + .destination(ipv4Address) + .topological() + .build(); + +getOs().getAdHocModule().sendV2XMessage(new MyV2XMessage(routing)); +``` +{{< figure src="../images/ad-hoc-topologically-scoped-unicast.png" +title="Ad-hoc topologically-scoped unicast" numbered="true" >}} + + +### Ad-hoc Geographically-Scoped Broadcast + +In Ad-Hoc communication the simulation entities act as active communication part (transmitter and +receiver). In geographically-scoped broadcast mode, all simulation entities within range and destination area are getting messages. + +As example in the following illustration, the rightmost vehicle sends a message, that is supposed to be transmitted to all vehicles within +the specified area (red circle). This is done by greedily forwarding the message via other vehicles until a vehicle within the area is +reached. Then, this vehicle broadcasts the message to all other vehicles within the area. + +{{< figure src="../images/ad-hoc-geographically-scoped-broadcast.png" +title="Ad-hoc geographically-scoped broadcast" numbered="true" >}} + +With the methods +* `.geographical(GeoCircle geoCircle)` +* `.geographical(GeoRectangle geoRectangle)` + +of the class `AdHocMessageRoutingBuilder`, we are able to configure the required area as a circle or a +rectangle. + +```java +GeoPoint center = GeoPoint.latlon(52.5, 13.2); + +GeoCircle adHocModule = new GeoCircle(center, 3000); + +MessageRouting routing = getOs().getAdHocModule().createMessageRouting() + .broadcast() + .geographical(adHocModule) + .build(); + +getOs().getAdHocModule().sendV2XMessage(new MyV2XMessage(routing)); +``` +Analogous to the examples above, we can also configure the transmission area as a rectangle. + +The next code snippet illustrates a possible configuration with a rectangular transmission area and a specified Ad-hoc +channel. + +```java +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().getAdHocModule().createMessageRouting() + .broadcast() + .geographical(transmissionArea) + .build(); + +getOs().getAdHocModule().sendV2XMessage(new MyV2XMessage(routing)); +``` + +### Ad-hoc Geographically-Scoped Unicast + +The class `AdHocMessageRoutingBuilder` can be used to configure a geographically-scoped unicast. Communication via this mode is possible +if the IP-address of the receiver is known, both (receiver and transmitter) are on the same Ad-hoc channel and the receiver is located in +specified `GeoArea`. + +The following picture illustrates a geographically-scoped ad-hoc unicast with multiple hops. The rightmost vehicle is the sender and is +addressing the leftmost vehicle via IP-Address and a given area (the red circle). The geographical routing protocol finds a message +routing using three hops, indicated by the black arrows. + +{{< figure src="../images/ad-hoc-geographically-scoped-unicast.png" +title="Ad-hoc geographically-scoped unicast" numbered="true" >}} + +Below you can see a possible configuration. + +```java +final byte[] ipv4Address = {127,36,50,4}; +GeoPoint center = GeoPoint.latlon(52.5, 13.2); +GeoCircle receivingArea = new GeoCircle(center, 3000); + +MessageRouting routing = getOs().getAdHocModule().createMessageRouting() + .destination(destAddress) + .geographical(receivingArea) + .build(); + +getOs().getAdHocModule().sendV2XMessage(new MyV2XMessage(routing)); +``` + +## Ad-hoc Channels +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. + +The following table shows the possible channels on the 5.9 GHz band used for V2X communication. + +| Channel Number | 0 | 1 | 2 | 3 | 4 | 5 | 6 | +|----------------|------|------|------|------|------|------|------| +| Channel Name | SCH1 | SCH2 | SCH3 | CCH | SCH4 | SCH5 | SCH6 | +| Frequency Band | 5.86 | 5.87 | 5.88 | 5.89 | 5.9 | 5.91 | 5.92 | + +Channels can be set via the `.channel(AdHocChannel)` method that is part of the `AdHocMessageRoutingBuilder`. +```java +AdHocChannel commonChannel = AdHocChannel.SCH1; + +MessageRouting routing = getOs().getAdHocModule().createMessageRouting() + .channel(commonChannel) + .broadcast() + .topological() + .singlehop() + .build(); + +getOs().getAdHocModule().sendV2XMessage(new MyV2XMessage(routing)); +``` + +{{% alert note %}} +The built-in Simple Network Simulator ([SNS](/docs/simulators/network_simulator_sns)) does not implement communication via different +channels. If that is the focus of your simulation, consider using a different network simulator like ([OMNeT++](/docs/simulators/network_simulator_omnetpp) or [ns-3](/docs/simulators/network_simulator_ns3)). +{{% /alert %}} \ No newline at end of file diff --git a/content/docs/develop_applications/communication-cell.md b/content/docs/develop_applications/communication-cell.md new file mode 100644 index 00000000..bebd0a50 --- /dev/null +++ b/content/docs/develop_applications/communication-cell.md @@ -0,0 +1,238 @@ +--- +title: Cellular Communication in Applications +linktitle: Communication - Cell +toc: true +type: docs +date: "2024-11-20T00:00:00+01:00" +draft: false +weight: 50 +menu: + docs: + parent: develop_applications + weight: 50 +--- + +Eclipse MOSAIC has different classes, which allow you to define the network type and the specific area where the +communication should occur. Cellular communication can be achieved with the built-in communication simulator [Eclipse MOSAIC Cell](/docs/simulators/network_simulator_cell). + +Depending on the needs of the application, there are different approaches to solve the communication issue in Eclipse MOSAIC +simulations. It is possible to modify the selected communication mode dependent on requirements. + +Generally, the following modes are available for cellular communication: + + * Geographically-scoped broadcast + * Geographically-scoped unicast + * Topologically-scoped unicast + +## General Configuration +The first step to enable your application to use communication capabilities, is to make sure it extends the `AbstractApplication`-class +with an `OperatingSystem` which provides a Cell module, such as `VehicleOperatingSystem`or `RoadSideUnitOperatingSystem`. +Additionally, if you want your application to act upon the reception or transmission of messages, make sure it implements the interface +`CommunicationApplication`. +Afterward, you can enable the cellular communication module by following the instruction in [Cellular Configuration](#cellular-communication). + +This example showcases the inheritance of an application class that can transmit and receive messages via Cell communication, once you have +enabled the module. +```java +public class CellApplication extends AbstractApplication implements CommunicationApplication {} +``` +--- + +## Cellular Communication + +The cellular network is known from wireless mobile communication and the principle is to divide the entire geographic +area into several smaller parts called **"cells"**. Each cell has a fixed-location transceiver with a coverage ratio. + +Eclipse MOSAIC enables the communication with all the existing vehicles via a geographically-scoped broadcast mode or direct communication +via a geographically-scoped unicast in a specific area (circular, rectangular). +In contrast, the topologically-scoped unicast mode is not restricted to a specific area. + + +### Cellular Configuration +To enable and configure the Cell-module in your application you have to call the `enable`-method of your applications Cell-module. +Typically, you will do this inside the `onStartup()`-method to enable cell capabilities from the get-go. + +Below is an example configuration defining maximal uplink and downlink bit rates. +```java +@Override +public void onStartup() { + getOs().getCellModule().enable(new CellModuleConfiguration() + .maxDownlinkBitrate(50 * DATA.MEGABIT) + .maxUplinkBitrate(50 * DATA.MEGABIT) + ); +} +``` + +## Cellular Routing Modes +There are several different routing modes for cellular communication, that differ in the route finding and number of receiving entities. +The following is an introduction into the most commonly used modes and how to use them within Eclipse MOSAIC. + +### Cellular Topologically-Scoped Unicast + +Compared to geographically-scoped uni- or broadcast, the topologically-scoped unicast is totally independent of geographical conditions +and the addressing can be in the form of an IP-Address or a receiver-ID. + +The next figure illustrates how the rightmost vehicle is communicating with vehicle below the RSU in topologically-scoped unicast mode. + +{{< figure src="../images/cellular-topologically-scoped-unicast.png" +title="Topologically-scoped unicast for direct addressing without geographical constraints" numbered="true" >}} + +The code example below shows how we can configure the requirements of the communication in topologically-scoped unicast mode. + +```java +String receiverName = "veh_0"; + +MessageRouting routing = getOs().getCellModule().createMessageRouting() + .destination(receiverName) + .topological() + .build(); + +getOs().getCellModule().sendV2XMessage(new MyV2XMessage(routing)); +``` + +### Cellular Geographically-Scoped Unicast + +Compared to a geographically-scoped broadcast, a geographically-scoped unicast addresses a receiver with a 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. + +Assume, the rightmost vehicle has a message which is addressed to the leftmost vehicle. In order to send the message, the sending vehicle +first examines whether the receiving vehicle is located within the transmission area. If this is the case, the +message will be transmitted. The figure below illustrates this procedure. + +{{< figure src="../images/cellular-geographically-scoped-unicast.png" +title="Cellular geographically-scoped unicast to address a receiver within a defined area " numbered="true" >}} + +The following methods are provided for configuring the transmission area (circle or rectangle) and the addressing to +the receiver(hostname or ip address): + +* `.geographical(GeoCircle geoCircle) ` +* `.geographical(GeoRectangle geoRectangle)` +* `.destination(byte[] ipAddress)` +* `.destination(Inet4Address ipAddress)` +* `.destination(String receiverName)` +* `.destination(NetworkAdress receiverName)` + +```java +GeoCircle transmissionArea = new GeoCircle( GeoPoint.latlon(52.5, 13.2), 3000); + +String receiverName = "veh_0"; +MessageRouting routing = getOs().getCellModule().createMessageRouting() + .destination(receiverName) + .geographical(transmissionArea) + .build(); + +getOs().getCellModule().sendV2XMessage(new MyV2XMessage(routing)); +``` + +### Cellular Geographically-Scoped Broadcast + +The principle function of the geographically-scoped broadcast 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. + +The following figure shows the rightmost vehicle, which is sending a message to be received by all vehicles in the red area. +The sending vehicle sends this message to a cellular antenna, which distributes it to all vehicles in the area. + +{{< figure src="../images/cellular-geographically-scoped-broadcast.png" +title="Illustration of geographically scoped broadcast in a specific circular area" numbered="true" >}} + +A circular communication area can be defined by adding the method `.geographical(GeoCircle geoCircle)` to the message routing builder +from an Eclipse MOSAIC application, as shown below: + +```java +GeoCircle transmissionArea = new GeoCircle(GeoPoint.latlon(52.5, 13.2), 3000); + +MessageRouting routing = getOs().getCellModule().createMessageRouting() + .broadcast() + .geographical(transmissionArea) + .build(); + +getOs().getCellModule().sendV2XMessage(new MyV2XMessage(routing)); +``` + +A rectangular destination area can be defined similarly: + +```java +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() + .broadcast() + .geographical(transmissionArea) + .build(); + +getOs().getCellModule().sendV2XMessage(new MyV2XMessage(routing)); +``` + +### Multicast/Broadcast Services +Multicast/Broadcast Services (MBS) is a point-to-multipoint interface specification for cellular networks. It is designed to provide +efficient delivery of broadcast and multicast services within a cell as well as within the core network. +MBS is a specialization of geographically-scoped routing and therefore can only be used in combination with it. + +The following methods are provided for configuring the use of MBS as a geographically-scoped routing protocol: +* `.mbs()` + +As described above, this can only be used in combination with the `.geographical(GeaArea)` method, see the example below: + +```java +GeoCircle transmissionArea = new GeoCircle( GeoPoint.latlon(52.5, 13.2), 3000); + +String receiverName = "veh_0"; +MessageRouting routing = getOs().getCellModule().createMessageRouting() + .destination(receiverName) + .geographical(transmissionArea) + .mbs() + .build(); + +getOs().getCellModule().sendV2XMessage(new MyV2XMessage(routing)); +``` + +### Setting Protocol Types + +By default, all cell messages use UDP, however you can set the protocol using the `.protocol(...)` method of the +`CellMessageRoutingBuilder`: +```java +String receiverName = "veh_0"; + +MessageRouting routing = getOs().getCellModule().createMessageRouting() + .protocol(Protocoltype.TCP) + .destination(receiverName) + .topological() + .build(); + +getOs().getCellModule().sendV2XMessage(new MyV2XMessage(routing)); +``` +--- + +## CAM - Implementation + +A Cooperative Awareness Messages (CAM) consists of four parts: + +* Header with generic information +* MessageBody +* ServiceList +* TaggedValue list + +First, generic information like protocol version, creation time stamp are submitted. Normally this data set follows a network beacon, which already contains data like position and speed. Nevertheless, this functionality must be implemented in the network layer, that means in the network simulator. At the moment this is not supported and is therefore compensated in the next message part, the message body. The body can contain either RSU or Vehicle awareness data. In the first case, only the RSU type is submitted, but this probably changes with a new CAM specification. In the second case, we provide date like vehicle width, length, position, speed, type and heading. The specification is not completely implemented, especially acceleration data and light, brake status are missing. The third part of the CAM specification, the service list, is also not implemented. This will probably change, when a list of services is defined by the ETSI. Last but not least a message contains a tagged list, a key value map with optional data. This is fully implemented and is used for our traffic light CAM messages, which provide the traffic light status in such a list. + +### User Defined Tagged Values + +If you are required to exchange custom data within CAMs, the field UserTaggedValue can be used. For adding such data to the CAM, the application needs to implement the method `beforeGetAndResetUserTaggedValue()` from the `CommunicationApplication` interface. If a CAM is about to be sent, the custom data can be set using the `getOs().setUserTaggedValue(byte[])` method. The receiver can simple access the data by accessing the field directly from the received CAM message: + +```java + byte[] value = cam.getUserTaggedValue (); + if (value != null) { + // read user tagged value} + } +``` + +### Timing Requirements + +CAMs are generated by the CAM Management and passed to lower layers when any of following rules apply: +* maximum time interval between CAM generations: $1s$; +* minimum time interval between CAM generations: $0.1s$; +* generate CAM when absolute difference between current heading (towards North) and last CAM heading > $4 deg$; +* generate CAM when distance between current position and last CAM position > $5m$ +* generate CAM when absolute difference between current speed and last CAM speed > $1ms$; +* These rules are checked latest every $100ms$; \ No newline at end of file diff --git a/content/docs/develop_applications/communication.md b/content/docs/develop_applications/communication.md deleted file mode 100644 index af6806f3..00000000 --- a/content/docs/develop_applications/communication.md +++ /dev/null @@ -1,389 +0,0 @@ ---- -title: Communication in Applications -linktitle: Communication -toc: true -type: docs -date: "2019-05-05T00:00:00+01:00" -draft: false -weight: 50 -menu: - docs: - parent: develop_applications - weight: 50 ---- - -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 ([OMNeT++](/docs/simulators/network_simulator_omnetpp), -[ns-3](/docs/simulators/network_simulator_ns3)) or one of the built-in communication simulators [SNS](/docs/simulators/network_simulator_sns) -or [Eclipse MOSAIC Cell](/docs/simulators/network_simulator_cell). Furthermore, for a better understanding it is important to consider the network types of Eclipse MOSAIC in more -detail. - -* Cellular Communication -* Ad-hoc Communication - -Depending on the needs of the application, there are different approaches to solve the communication issue in Eclipse MOSAIC -simulations. However, a distinction must be made between inter vehicle communication and Vehicle-to-X communication. -Also, it is possible to modify the selected communication mode dependent on requirements. - -Generally, the following modes are available based on network: - -**Cellular Communication** - * Geobroadcast - * Geocast - * Topocast - -**Ad-hoc Communication** - * Geobroadcast - * Geocast - * Topobroadcast - * Topocast - -## General Configuration -The first step to enable your application to use communication capabilities, is to make sure it extends the `AbstractSimulationUnit`-class -or one of its child-classes (e.g. `VehicleUnit`, `ChargingStationUnit`) found in package -`org.eclipse.mosaic.fed.application.ambassador.simulation`. Additionally, if you want your application to act upon -the reception or transmission of messages, make sure it implements the interface `CommunicationApplication`. -Afterwards, depending on your use case, you can enable the desired communication modules following the instruction in -[Cellular Configuration](#cellular-communication) and [Ad-hoc Configuration](#ad-hoc-configuration). - ---- - -## Cellular Communication - -The cellular network is known from wireless mobile communication and the principle is to divide the entire geographic -area into several smaller parts called **"cells"**. Each cell has a fixed-location transceiver with a coverage ratio. - -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. - -### Cellular Configuration -To enable and configure the Cell-module in your application you have to call the `enable`-method of your applications Cell-module. -Typically, you will do this inside the `onStartup()`-method to enable cell capabilities from the get-go. - -Below is an example configuration defining maximal uplink and downlink bit rates. -```java -@Override -public void onStartup() { - getOs().getCellModule().enable(new CellModuleConfiguration() - .maxDownlinkBitrate(50 * DATA.MEGABIT) - .maxUplinkBitrate(50 * DATA.MEGABIT) -} -``` - -### Cellular Geobroadcast - -The principle function of the Geobroadcast is to communicate with all entities within a geographical area. Eclipse MOSAIC -offers the possibility to configure a specific geographical area which can be either a circular or a rectangular area. - -The following figure illustrates a vehicle ***veh_2*** which is communicating with the other -vehicles(***veh_1***, ***veh_3***) within a radius **R**. - -{{< figure src="../images/tiergarten-geobroadcast-circular-area.png" title="Illustration of Geobroadcast in a specific circular area" numbered="true" >}} - -A circular communication area can be defined with the `geoBroadCast(GeoCircle geoCircle)` from an Eclipse MOSAIC application, -as shown below: - -```java -GeoCircle transmissionArea = new GeoCircle(GeoPoint.latlon(52.5, 13.2), 3000); - -MessageRouting routing = getOs().getCellModule().createMessageRouting().geoBroadCast(transmissionArea); - -getOs().getCellModule().sendV2XMessage(new MyV2XMessage(routing)); -``` - -A rectangular destination area can be defined similarly: - -```java -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)); -``` - -### Cellular Geocast - -Compared to Geobroadcasting, a Geocast addresses a receiver with an unique address. Addressing can be in the form of an -IP-Address or a receiver-ID (e.g. veh_0). Again, the communication area can be configured as circular or rectangular. - -Assume, the ***veh_1*** has a message which is addressed to ***veh_2***. In order to send the message, ***veh_1*** first -examines whether the vehicle with ID ***veh_2*** is located within the transmission area. If this is the case, the -message will be transmitted. In figure below is this situation illustrated. - -{{< figure src="../images/tiergarten-geocast-circular-area.png" title="Cellular Geocast to address a receiver within a defined area " numbered="true" >}} - -The following methods are provided for the configuring the transmission area (Circle or Rectangle) and the addressing to -the receiver(hostname or ip address). - -* `geoCast(GeoCircle geoCircle, String receiverName) ` -* `geoCast(GeoRectangle geoRectangle, String receiverName)` -* `geoCast(GeoCircle geoCircle, byte[] ipAddress)` -* `geoCast(GeoRectangle geoRectangle, byte[] ipAddress)` - -```java -GeoCircle transmissionArea = new GeoCircle( GeoPoint.latlon(52.5, 13.2), 3000); - -String receiverName = "veh_0"; -MessageRouting routing = getOs().getCellModule().createMessageRouting().geoCast(transmissionArea, receiverName); - -getOs().getCellModule().sendV2XMessage(new MyV2XMessage(routing)); -``` - -### Cellular Topocast - -Compared to Geocast or Geobroadcast, the Topocast is totally independent of geographical conditions and the addressing -can be in the form of an IP-Address or a receiver-ID. - -The next figure illustrates how the ***veh_0*** is communicating with ***veh_1*** in Topocast mode. - -{{< figure src="../images/tiergarten-cellular-topocast.png" title=" Topocast mode for direct addressing without geographical constraints" numbered="true" >}} - -The code example below shows how we can configure the requirements of the communication in Topocast mode. - -```java -String receiverName = "veh_0"; - -MessageRouting routing = getOs().getCellModule().createMessageRouting().topoCast(receiverName); - -getOs().getCellModule().sendV2XMessage(new MyV2XMessage(routing)); -``` - -### Setting Protocol Types - -By default, all cell messages use UDP, however you can set the protocol using the `protocol(...)` method of the `MessageRoutingBuilder`: -```java -String receiverName = "veh_0"; - -MessageRouting routing = getOs().getCellModule().createMessageRouting() - .protocol(Protocoltype.TCP) - .topoCast(receiverName); - -getOs().getCellModule().sendV2XMessage(new MyV2XMessage(routing)); -``` ---- - -## Ad-hoc Communication - -The Ad-hoc network does not rely on a pre-existing infrastructure. Provided that vehicles are equipped with Ad-hoc -modules, they are able to communicate with each other dynamically. In case of a sufficient number of Ad-hoc equipped -vehicles, a message can be transferred via hops quickly over a long distance. - -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. - -The following table shows the possible channels on the 5.9 GHz band used for V2X communication. - -|Channel Number| 0 | 1 | 2 | 3 | 4 | 5 | 6 | -|--------------| - | - | - | - | - | - | - | -|Channel Name | SCH1| SCH2 | SCH3 | CCH | SCH4 | SCH5 | SCH6| -|Frequency Band| 5.86 | 5.87 | 5.88 | 5.89 |5.9 | 5.91 | 5.92 | - -### Ad-hoc Configuration -Make sure you set up your application as described in [General Configuration](#general-configuration). -Afterwards, to configure and enable the AdHoc-module in your application you have to call the `enable`-method of your applications' -Adhoc-module and define a configuration. -Usually you will do this in the `onStartup()`-method to enable the module from the get-go. -Below is an example configuration taken from the Tiergarten-tutorial. Instead of configuring the `.power(...)[mW]` -it is also possible to configure a `.distance(...)[m]`. -```java -@Override -public void onStartup() { - getOs().getAdHocModule().enable(new AdHocModuleConfiguration() - .addRadio() - .channel(AdHocChannel.CCH) - .power(50) - .create()); - } -``` - -### Ad-hoc Topobroadcast - -In Topobroadcast mode, the communication between vehicles is regardless of the geographic conditions. However, the -communicating entities must be operated on the same Ad-hoc channel and there are two options to use the Topobroadcast: -* Singlehop -* Multihop - -#### Singlehop Approach in Topobroadcast - -For Singlehop, it is not necessary to specify the number of hops explicitly which indicates the lifespan of a message, -because in Singlehop, any message has a lifespan of **hop = 1**. Moreover, Eclipse MOSAIC allows to use the default method -`topoBroadCast()` which automatically assigns a Control Channel (CCH) for the simulation entity and a lifespan based on -the Singlehop principle. Alternatively you can use the non-default method `topoBroadCast(AdHocChannel)` in order to -specify the Ad-hoc channel. - -Below are some configuration examples of the default addressing method `topoBroadCast()` and non-default addressing -method `topoBroadCast(AdHocChannel)`. - -```java -MessageRouting routing = getOs().getAdHocModule().createMessageRouting().topoBroadCast(); - -getOs().getAdHocModule().sendV2XMessage(new MyV2XMessage(routing)); -``` - -```java -AdHocChannel commonChannel = AdHocChannel.SCH1; - -MessageRouting routing = getOs().getAdHocModule().createMessageRouting().topoBroadCast(commonChannel); - -getOs().getAdHocModule().sendV2XMessage(new MyV2XMessage(routing)); -``` -The following figure shows a simplified model based on the Singlehop principle. The *veh_1* sends messages to all -simulation entites(***RSU***, ***veh_2***) that are using the same Ad-hoc channel. After transmission, the message can -no longer be forwarded by the receiver. - -{{< figure src="../images/tiergarten-adhoc-topobroadcast-singlehop.png" title="Overview Singlehop with specified Ad-hoc channel" numbered="true" >}} - -#### Multihop Approach in Topobroadcast - -In Multihop, the lifespan (amount of hops) of a message can be specified, allowing larger communication distances. - -The following figure shows a Multihop example with a data package D (M, h = 2) from the vehicle *veh_0* which contains a -message M and a hop number h = 2. Assuming that a lot of simulation entities are using the same Ad-hoc channel the -message can be forwarded over a along distance. After each forward the hop number will be incremented by 1. Since the -hop amount was set to 2, the forwarding will stop after 2 increments. - -{{< figure src="../images/tiergarten-adhoc-topobroadcast.png" title="Overview Multihop principle" numbered="true" >}} - -The next code snippet shows a configuration example with an Ad-hoc channel and a message lifespan **hops = 2**. - -```java -int hops = 2; - -MessageRouting routing = getOs().getAdHocModule().createMessageRouting().topoBroadCast(hops); - -getOs().getAdHocModule().sendV2XMessage(new MyV2XMessage(routing)); -``` - -{{% alert note %}} -In order to use the Multihop approach in OMNeT++ and ns-3 provided by Eclipse MOSAIC, its necessary to implement a -routing protocol in network simulators ([OMNeT++](/docs/simulators/network_simulator_omnetpp), -[ns-3](/docs/simulators/network_simulator_ns3)). But the built in communication simulator -[SNS](/docs/simulators/network_simulator_sns) includes a simple routing protocol "Flooding". -{{% /alert %}} - -### Ad-hoc Topocast - -In addition to the Topobroadcast, the communication in Topocast mode will be addressed explicitly to the recipient and -the addressing can be done either through receiver name (vehicle-ID e.g. veh_0) or the IP-Address of the vehicle. - -```java -final byte[] ipv4Address = {127,36,50,4}; - -AdHocChannel commonChannel = AdHocChannel.SCH1; - -int hops = 2; - -MessageRouting routing = getOs().getAdHocModule().createMessageRouting().topoCast(ipv4Address, hops); - -getOs().getAdHocModule().sendV2XMessage(new MyV2XMessage(routing)); -``` - -### Ad-hoc Geobroadcast - -In contrast to Cellular Network above, the simulation entities act as active communication part (transmitter and -receiver) and all simulation entities within range are getting messages in Geobroadcast mode. - -As example in the following illustration, The vehicles ***veh_0***, ***veh_2***, ***veh_3*** and the ***RSU*** are -Ad-hoc equipped and there is no vehicle in the communication range of ***RSU***, therefore a hop is not possible to next -vehicle ***veh_0***. But the vehicles ***veh_2*** and ***veh_3*** are able to communicate with each other. - -{{< figure src="../images/tiergarten-adhoc-network.png" title="Principle of Ad-hoc Geobroadcast mode" numbered="true" >}} - -With the methods -* `geoBroadCast(GeoCircle geoCircle)` -* `geoBroadCast(GeoRectangle geoRectangle)` - -of the Eclipse MOSAIC class `AdHocMessageRoutingBuilder` ,we are able, to configure the required area as a circle or a -rectangle. -```java -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)); -``` -Analogous to the examples above, we can also configure the transmission area as a rectangle. - -The next code snippet illustrates a possible configuration with a rectangular transmission area and a specified Ad-hoc -channel. - -```java -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().getAdHocModule().createMessageRouting().geoBroadCast(transmissionArea, AdHocChannel.SCH1); - -getOs().getCellModule().sendV2XMessage(new MyV2XMessage(routing)); -``` - -### Ad-hoc Geocast - -The class AdHocMessageRoutingBuilder only has one method for Geocasting mode, - `geoCast(DestinationAddress destinationAddress, AdHocChannel adHocChannel)`. Communication is possible if the - IP-address of receiver is known and both (receiver and transmitter) are on the same Ad-hoc channel. - -{{% alert note %}} -In this context the name Geocast is misleading, because a geological condition is not necessary. -{{% /alert %}} - -As you can see in the next picture, the RSU uses the Ad-hoc channel *SCH1* and several vehicles use different -Ad-hoc channels. Assuming the RSU tries to send a message to *veh_1* and has knowledge about the IP-Address of *veh_1*, -if the vehicle *veh_1* also uses the same channel *SCH1*, the transmission will be completed successfully. - -{{< figure src="../images/tiergarten-geocast-adHoc.png" title="Ad-hoc Geocast communication between entities using the same channel" numbered="true" >}} - -Below you can see a possible configuration. - -```java -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)); -``` - -## CAM - Implementation - -A Cooperative Awareness Messages (CAM) consists of four parts: - -* Header with generic information -* MessageBody -* ServiceList -* TaggedValue list - -First, generic information like protocol version, creation time stamp are submitted. Normally this data set follows a network beacon, which already contains data like position and speed. Nevertheless, this functionality must be implemented in the network layer, that means in the network simulator. At the moment this is not supported and is therefore compensated in the next message part, the message body. The body can contain either RSU or Vehicle awareness data. In the first case, only the RSU type is submitted, but this probably changes with a new CAM specification. In the second case, we provide date like vehicle width, length, position, speed, type and heading. The specification is not completely implemented, especially acceleration data and light, brake status are missing. The third part of the CAM specification, the service list, is also not implemented. This will probably change, when a list of services is defined by the ETSI. Last but not least a message contains a tagged list, a key value map with optional data. This is fully implemented and is used for our traffic light CAM messages, which provide the traffic light status in such a list. - -### User Defined Tagged Values - -If you are required to exchange custom data within CAMs, the field UserTaggedValue can be used. For adding such data to the CAM, the application needs to implement the method `beforeGetAndResetUserTaggedValue()` from the `CommunicationApplication` interface. If a CAM is about to be sent, the custom data can be set using the `getOs().setUserTaggedValue(byte[])` method. The receiver can simple access the data by accessing the field directly from the received CAM message: - -```java - byte[] value = cam.getUserTaggedValue (); - if (value != null) { - // read user tagged value} - } -``` - -### Timing Requirements - -CAMs are generated by the CAM Management and passed to lower layers when any of following rules apply: -* maximum time interval between CAM generations: $1s$; -* minimum time interval between CAM generations: $0.1s$; -* generate CAM when absolute difference between current heading (towards North) and last CAM heading > $4 deg$; -* generate CAM when distance between current position and last CAM position > $5m$ -* generate CAM when absolute difference between current speed and last CAM speed > $1ms$; -* These rules are checked latest every $100ms$; \ No newline at end of file diff --git a/content/docs/develop_applications/event_scheduling.md b/content/docs/develop_applications/event_scheduling.md index e27019d4..13c1ea3f 100644 --- a/content/docs/develop_applications/event_scheduling.md +++ b/content/docs/develop_applications/event_scheduling.md @@ -18,7 +18,7 @@ Applications are implemented by reacting to specific events. Those events are, a * Once a vehicle has been added to the simulation, all its configured applications are initialized (`onStartup()` is called) * The data of the vehicle has changed, e.g. after the traffic simulator has finished one simulationstep (`onVehicleUpdated()` is called). * A unit has received a V2X message from another entity (`onMessageReceived` is called). -* A unit which has send a V2X message via a ITS-G5 topocast receives an acknowledgement (`onAcknowledgementReceived()` is called). +* A unit which has sent a V2X message via a topologically-scoped ITS-G5 unicast receives an acknowledgement (`onAcknowledgementReceived()` is called). Another example: diff --git a/content/docs/develop_applications/images/ad-hoc-geographically-scoped-broadcast.png b/content/docs/develop_applications/images/ad-hoc-geographically-scoped-broadcast.png new file mode 100644 index 00000000..f523352b Binary files /dev/null and b/content/docs/develop_applications/images/ad-hoc-geographically-scoped-broadcast.png differ diff --git a/content/docs/develop_applications/images/ad-hoc-geographically-scoped-unicast.png b/content/docs/develop_applications/images/ad-hoc-geographically-scoped-unicast.png new file mode 100644 index 00000000..a7de1818 Binary files /dev/null and b/content/docs/develop_applications/images/ad-hoc-geographically-scoped-unicast.png differ diff --git a/content/docs/develop_applications/images/ad-hoc-topologically-scoped-broadcast.png b/content/docs/develop_applications/images/ad-hoc-topologically-scoped-broadcast.png new file mode 100644 index 00000000..83bc3984 Binary files /dev/null and b/content/docs/develop_applications/images/ad-hoc-topologically-scoped-broadcast.png differ diff --git a/content/docs/develop_applications/images/ad-hoc-topologically-scoped-unicast.png b/content/docs/develop_applications/images/ad-hoc-topologically-scoped-unicast.png new file mode 100644 index 00000000..7287846e Binary files /dev/null and b/content/docs/develop_applications/images/ad-hoc-topologically-scoped-unicast.png differ diff --git a/content/docs/develop_applications/images/cellular-geographically-scoped-broadcast.png b/content/docs/develop_applications/images/cellular-geographically-scoped-broadcast.png new file mode 100644 index 00000000..fd925ae8 Binary files /dev/null and b/content/docs/develop_applications/images/cellular-geographically-scoped-broadcast.png differ diff --git a/content/docs/develop_applications/images/cellular-geographically-scoped-unicast.png b/content/docs/develop_applications/images/cellular-geographically-scoped-unicast.png new file mode 100644 index 00000000..8e392aa5 Binary files /dev/null and b/content/docs/develop_applications/images/cellular-geographically-scoped-unicast.png differ diff --git a/content/docs/develop_applications/images/cellular-topologically-scoped-unicast.png b/content/docs/develop_applications/images/cellular-topologically-scoped-unicast.png new file mode 100644 index 00000000..89754ac2 Binary files /dev/null and b/content/docs/develop_applications/images/cellular-topologically-scoped-unicast.png differ diff --git a/content/docs/develop_applications/navigation.md b/content/docs/develop_applications/navigation.md index 9323c957..25def316 100644 --- a/content/docs/develop_applications/navigation.md +++ b/content/docs/develop_applications/navigation.md @@ -13,7 +13,7 @@ menu: --- The navigation of vehicles (i.e. calculation of routes) is handled completely by the [Application Simulator](/docs/simulators/application_simulator#eclipse-mosaic-application-simulator). Each vehicle is equipped -with a navigation system which provides all required information and functions for navigational purposes: +with a `NavigationModule` which provides all required information and functions for navigational purposes: * Retrieve the current position and heading of the vehicle. * Get the target of the vehicle. @@ -26,8 +26,8 @@ needs to be transformed before the simulation using scenario-convert (see [Creat The map data including initial routes for vehicles is provided with the database file which needs to be located in `mosaic/scenarios//application/.db`. Further information about the database can be found in the [scenario database](/docs/develop_applications/scenario_database) documentation. -To enable non-moving entities (i.e. RSUs, Servers, ...) to access routing capabilities the `IRoutingModule` can be implemented -which omits operations like route switching. +To access routing capabilities for non-moving entities (i.e. RSUs or Servers), the `getRoutingModule()` method can be used, +which provides similar functionality as the navigation module except route switching. ## Configuration If the database needs to be located somewhere else, the path can be specified in @@ -50,7 +50,7 @@ The following snippet shows, how the navigation system can be used within an app ```java //get navigation module -INavigationModule navigationModule = getOs().getNavigationModule(); +NavigationModule navigationModule = getOs().getNavigationModule(); //choose current target as target position RoutingPosition targetPosition = new RoutingPosition(navigationModule.getTargetPosition()); diff --git a/content/docs/develop_applications/operating_system.md b/content/docs/develop_applications/operating_system.md index 0c1b089a..12e72ad2 100644 --- a/content/docs/develop_applications/operating_system.md +++ b/content/docs/develop_applications/operating_system.md @@ -94,5 +94,6 @@ this.getOs().stop(distance, duration, Stop.StopMode.PARK); ### Learn More About Operating System Modules - [Navigation Module](/docs/develop_applications/navigation) -- [Communication Module](/docs/develop_applications/communication) +- [Ad-Hoc Communication Module](/docs/develop_applications/communication-ad-hoc) +- [Cellular Communication Module](/docs/develop_applications/communication-cell) - [Perception Module](/docs/develop_applications/perception) \ No newline at end of file diff --git a/content/docs/scenarios/files/steglitz_visualizer_config.xml b/content/docs/scenarios/files/steglitz_visualizer_config.xml index baa18278..1dcee6fe 100644 --- a/content/docs/scenarios/files/steglitz_visualizer_config.xml +++ b/content/docs/scenarios/files/steglitz_visualizer_config.xml @@ -1,7 +1,7 @@  - + VehicleTravelTimes Time:0,1000 diff --git a/content/docs/scenarios/scenario_configuration.md b/content/docs/scenarios/scenario_configuration.md index ddb1b267..35f7c7d5 100644 --- a/content/docs/scenarios/scenario_configuration.md +++ b/content/docs/scenarios/scenario_configuration.md @@ -136,7 +136,7 @@ Finally, make sure the visualization federate is activated in the `scenario_conf ``` Now we have to configure the statistics visualizer itself. This [visualizer_config.xml](/docs/scenarios/files/steglitz_visualizer_config.xml) contains the basic -configuration in order to calculate the average travel times for the vehicles. If you want to make adaptions, please +configuration to calculate the average travel times for the vehicles. If you want to make adaptions, please refer to [statistics visualizer](/docs/visualization/statistics). Go ahead and run the simulation one more time. Afterwards the log-directory should contain a file called `AverageVehicleTravelTime.csv` in a directory called `StatisticsVisualizer`: diff --git a/content/docs/simulators/network_simulator_cell.md b/content/docs/simulators/network_simulator_cell.md index 3f602b84..35bc81ce 100644 --- a/content/docs/simulators/network_simulator_cell.md +++ b/content/docs/simulators/network_simulator_cell.md @@ -346,13 +346,15 @@ Application Simulator. It supports the following addressing and casting schemes. -**[CellTopocast](/docs/develop_applications/communication#cellular-topocast)** is the normal unicast, where the Geocaster simply resolves -the single receiver via theIPResolver. Hence, the CellTopocast directly routes the message further. Currently, Topocast doesn't allow -broadcast or anycast addresses, but any transmission protocols (tcp, udp). +**[CellTopocast](/docs/develop_applications/communication-cell#cellular-topologically-scoped-unicast)** is a topologically-scoped unicast, +where the Geocaster simply resolves the single receiver via the IPResolver. Hence, the CellTopocast directly routes the message further. +The cell simulator can **only** simulate topologically-scoped unicasts. Broadcast and anycast are not implemented, +but any transmission protocol can be used (tcp, udp). -**[CellGeoUnicast](/docs/develop_applications/communication#cellular-geocast)** addresses every node in the destination area individually. +**[CellGeoUnicast](/docs/develop_applications/communication-cell#cellular-geographically-scoped-unicast)** +addresses every node in the destination area individually. In this way it takes a geographic address and results in a loop to generate multiple unicasts. -**[CellGeoBroadcast](/docs/develop_applications/communication#cellular-geobroadcast)**, which is basically MBMS, uses one broadcast to all -nodes in the destined regions.The MBMS uses the different transmission mode of multicast in the downlink. CellGeoUnicast as well as -CellGeoBroadcast require broadcast, but don’t allow tcp (as ack for broadcasts is denied). +**[CellGeoBroadcast](/docs/develop_applications/communication-cell#cellular-geographically-scoped-broadcast)**, which is basically MBMS, +uses one broadcast to all nodes in the destined regions.The MBMS uses the different transmission mode of multicast in the downlink. +CellGeoUnicast as well as CellGeoBroadcast require broadcast, but don’t allow tcp (as ack for broadcasts is denied). diff --git a/content/docs/simulators/network_simulator_sns.md b/content/docs/simulators/network_simulator_sns.md index 085f1148..2a25039e 100644 --- a/content/docs/simulators/network_simulator_sns.md +++ b/content/docs/simulators/network_simulator_sns.md @@ -73,48 +73,59 @@ Read the detailed documentation of the [SNS Configuration](/docs/mosaic_configur {{% /alert %}} ## Transmission Logic -SNS differentiates between two types of Ad-hoc transmissions, geographically- and topologically-scoped transmissions, which -generally are abbreviated with _GeoCast_ and _TopoCast_ respectively. -GeoCasts are limited to _BroadCasts_. Accordingly, there is no explicit addressing -of receivers (other than 255.255.255.255), instead a destination area is specified. However, GeoCasts allow for multihop forwarding. -TopoCasts on the other hand use means of IPv4 addressing to transmit messages. Since the SNS was not build to simulate transmissions using complex topology-constructs, TopoCasts -are limited to transmissions with a single hop. However, TopoCasts support _BroadCasts_ and _UniCasts_ (we are omitting Anycasts). +SNS differentiates between two types of Ad-hoc transmissions, geographically- and topologically-scoped transmissions. +Geographically- as well as topologically-scoped casts allow for singlehop or multihop forwarding. The only exception is the +topologically-scoped broadcast, which does not allow for multiple hops. +Furthermore, no form of anycast is implemented in SNS. +Geologically-scoped casts specify a destination area. Topologically-scoped casts on the other hand use means of IPv4 addressing to transmit +messages. Most transmissions in the Ad-hoc domain will be some form of Broadcast, meaning every reachable entity is eligible to -receive a message. +receive a message. -{{< svg src="images/sns_transmission_logic_flowchart.svg" desc="This flowchart tells how different types of messages are handled internally." >}} +For an overview over which transmission logic implemented in SNS, as well as other network simulators see the +[Communication](/docs/develop_applications/communication-ad-hoc.md) page. -### TopoCasts -The only way of directly addressing entities is a _SingleHopUniCast_ (see figure below), the sender will try to address an entity +{{< svg src="images/sns_transmission_logic_flowchart.svg" +desc="This flowchart tells how different types of messages are handled internally." >}} + +### Topologically Scoped Casts +A way of directly addressing entities is a singlehop unicast (see figure below). The sender will try to address a given entity in its transmission range. {{< figure src="../images/SingleHopUniCast.png" title="SingleHopUniCast: The RSU is directly addressing the green vehicle." >}} -The counterpart to that is a _SingleHopBroadCast_ (see figure below), this form of transmission is commonly used for CAMs (Cooperative Awareness Messages) -and other types of intermediate warning messages to all entities in transmission range. +The counterpart to that is a singlehop broadcast (see figure below). This form of transmission is commonly used for CAMs +(Cooperative Awareness Messages) and other types of immediate warning messages to all entities in transmission range. {{< figure src="../images/SingleHopBroadCast.png" title="SingleHopBroadCast: The RSU is addressing all units in transmission range." >}} -### GeoCasts -As already explained, GeoCasts do not support direct addressing, so there is no form of UniCast. Instead of addressing -entities, GeoCasts specify a destination area in which a message should be distributed. -The SNS supports two ways to simulate GeoCasts. +### Geographically-Scoped Casts +Geographically-scoped casts specify a destination area in which a message should be distributed. A broadcast would distribute the message +to every entity in the destination area, while a unicast would only be sent successfully if the specified receiver is located in the +destination area. + +The SNS supports two ways to simulate geographically-scoped casts. A simple but performant model (`SimpleAdhocTransmissionModel`) & a fairly realistic model ( `SophisticatedAdhocTransmissionModel`). -The simple model assumes a transmission to all entities in the specified area, whereas the delay will be calculated using the configured delay-type and the successful reception will be determined by the uniformly distributed lossProbability. +The simple model assumes a transmission to all entities in the specified area, whereas the delay will be calculated using the configured +delay-type and the successful reception will be determined by the uniformly distributed lossProbability. The figure below depicts this behaviour -{{< figure src="../images/SimpleMultiHop.png" title="Simple GeoBroadCast: The RSU is sending to all entities in the destination area. All arrows (transmissions) will have a uniquely calculated delay or possible loss." >}} +{{< figure src="../images/SimpleMultiHop.png" +title="Simple GeoBroadCast: The RSU is sending to all entities in the destination area. All arrows (transmissions) will have a uniquely calculated delay or possible loss." >}} The realistic model accounts for possible transmission failures more accurately. The easiest case is that the sender itself is inside -of the destination area (or is able to communicate with an entity inside the destination area) and will start a [Flooding Transmission](#flooding-transmission) within this area (see figure below). -{{< figure src="../images/FloodingTransmission.png" title="GeoBroadCast using [Flooding Transmission](#flooding-transmission). Note: the area is not limited to circles." >}} +the destination area (or is able to communicate with an entity inside the destination area) and will start a [Flooding Transmission](#flooding-transmission) +within this area (see figure below). +{{< figure src="../images/FloodingTransmission.png" +title="GeoBroadCast using [Flooding Transmission](#flooding-transmission). Note: the area is not limited to circles." >}} -In case the sending entity is outside of the destination area, a [Forwarding Transmission](#approaching-transmission) has to -be executed first. This is can also be described as an _AnyCast_, since the goal of this transmission is to reach _any_ entity +In case the sending entity is outside the destination area, a [Forwarding Transmission](#approaching-transmission) has to +be executed first. This can also be described as an anycast, since the goal of this transmission is to reach _any_ entity inside the destination area. We try to achieve this by building a "chain" of entities, that will forward the message to the destination are (see figure below). {{< figure src="../images/ApproachingTransmission.png" title="Forwarding Transmission, by building a \"chain\" of vehicles." >}} The SNS however never uses [Forwarding Transmissions](#approaching-transmission) individually, rather they are combined with a [Flooding Transmission](#flooding-transmission), which -will simulate a way, that GeaCasts can be implemented in reality. The figure below depicts this behaviour. -{{< figure src="../images/ApproachingAndFlooding.png" title="Forwarding Transmission followed by a [Flooding Transmission](#flooding-transmission) to realistically simulate GeoCasts." >}} +will simulate a way, that a geographically-scoped transmission can be implemented in reality. The figure below depicts this behaviour. +{{< figure src="../images/ApproachingAndFlooding.png" +title="Forwarding Transmission followed by a [Flooding Transmission](#flooding-transmission) to realistically simulate geographically-scoped casts." >}} ## Transmission Models As already mentioned in the previous abstracts, the SNS supports different transmission models for different use cases. @@ -124,9 +135,9 @@ a detailed inside in the workings of the models. ### `SimpleAdhocTransmissionModel` This is the most basic of all transmission models and will be your model of choice if you are not interested in completely -accurate transmission results but care for performance. This model will approximate GeoCasts using the defined `simpleMultihopDelay` -and `simpleMultihopTransmission` parameters. -For TopoCasts the usual `singlehopDelay` will be used. +accurate transmission results but care for performance. This model will approximate geographically-scoped casts using the defined +`simpleMultihopDelay` and `simpleMultihopTransmission` parameters. +For topologically-scoped casts the usual `singlehopDelay` will be used. This model only checks, whether a potential receiver is inside the destination area and has enabled Adhoc capabilities. If those conditions are met it will simulate the transmission by calculating an actual delay value and saving it into a transmission-result. Such a result holds information of the success of the transmission, the delay-value, the amount of hops, @@ -135,9 +146,9 @@ and the number of attempts. Though the amount of hops will always be 1 for this ### `SophisticatedAdhocTransmissionModel` This model offers are more realistic simulation of adhoc transmissions, using an implementation of a greedy-forwarding and flooding algorithm (see [greedy forwarding](https://en.wikipedia.org/wiki/Geographic_routing) & -[flooding](https://en.wikipedia.org/wiki/Flooding_(computer_networking))). For TopoCasts this model behaves very -similarly to the `SimpleAdhocTransmissionModel`, since TopoCasts are always configured with only one hop. -For GeoCasts however, this model follows the flowchart above, trying to "approach" a destination area if it can't be reached directly. +[flooding](https://en.wikipedia.org/wiki/Flooding_(computer_networking))). For topologically-scoped casts this model behaves very +similarly to the `SimpleAdhocTransmissionModel`, since topologically-scoped casts are always configured with only one hop. +For geographically-scoped casts however, this model follows the flowchart above, trying to "approach" a destination area if it can't be reached directly. #### Approaching (Greedy forwarding) Approaching can be imagined as building a "chain" of entities to reach an area. However, there is no @@ -165,12 +176,12 @@ in real world implementations. #### Implementing your own `AdhocTransmissionModel` If the implemented models don't suffice your needs you can easily implement your own. -Create a class extending `AdhocTransmissionModel` and implement the abstract methods for sending TopoCasts/GeoCasts. -A possible extension could be to allow for multihop TopoCasts, building an actual topology and transmit your -messages using that topology. Also, the aforementioned "Face-Routing" could be of interest. Additionally, the calculation -of delays could be made more realistic. +Create a class extending `AdhocTransmissionModel` and implement the abstract methods for sending +topologically-scoped casts/geographically-scoped casts. A possible extension could be to allow for multihop topologically-scoped casts, +building an actual topology and transmit your messages using that topology. Also, the aforementioned "Face-Routing" could be of interest. +Additionally, the calculation of delays could be made more realistic. ## Accessing SNS-functionality from your applications To enable SNS in your scenario follow the steps as described in [Scenario Configuration](docs/scenarios/scenario_configuration#communication-simulators-cell-ns3-omnetpp-sns). An overview of how to configure AdHoc-modules and usage of the API for Routing and Message-Building functions, -can be found under [Application Development](docs/develop_applications/communication). +can be found under [Application Development](docs/develop_applications/communication-ad-hoc). diff --git a/content/docs/visualization/statistics.md b/content/docs/visualization/statistics.md index 7980629a..83b85f6f 100644 --- a/content/docs/visualization/statistics.md +++ b/content/docs/visualization/statistics.md @@ -17,7 +17,7 @@ For further information on licenses, feel free to contact us via **[mosaic@fokus {{% /alert %}} Statistics Output is another output generating tool to easily measure basic simulation outcomes. -You will be able to obtain short or detailed results of the simulation, e.g. travel times or the average speeds +You will be able to obtain short or detailed results of the simulation, e.g., travel times or the average speeds of groups of vehicles, or the average flow on induction loops. ## Configuration @@ -28,7 +28,7 @@ In order to use the Statistics Output, the attribute `enabled` of the root eleme set to "true", as shown in the following listing. ```xml - + [...] @@ -54,8 +54,8 @@ attribute has not been given, each `` block will get the name accordi for example `1. StatisticsVisualizer-Block.csv`. In the output attribute two options (`short`|`verbose`) can be selected. The short option provides us -a compact log file with information about only the highest level of the retrieved data (e.g. aggregate -values of grouped vehicles) in contrast to verbose option which also provides informations about every +a compact log file with information about only the highest level of the retrieved data (e.g., aggregate +values of grouped vehicles) in contrast to the verbose option which also provides information about every individual vehicle in each group. For a successful start, the element source must be placed in the first position in the `statistic` children @@ -76,17 +76,17 @@ individual requirements. Next to retrieving raw data, the Statistics Output has processing of the obtained data. 1. `source`: Data to obtain, choose between: - * `VehicleSpeeds` - Obtain the speeds of the vehicles of each simulation step. + * `VehicleSpeeds` - Obtain the speeds of the vehicles within each simulation step. * `VehicleStops` - The total number of stops during the journey of each vehicle. * `VehicleTravelTimes` - The total travel time in s of the vehicles. * `VehicleDelayTimes` - The deviation of the travel time compared to the fastest travel time possible for the vehicles (in s). - * `VehicleTravelledDistances` - The travelled distance of the vehicles in m. + * `VehicleTravelledDistances` - The traveled distance of the vehicles in m. * `VehicleFuelConsumptions` - The fuel consumptions of the vehicles in l per km. - * `VehicleHeadways` - Obtain the headway towards the leading vehicle of each vehicle for each simulation step. To obtain this value, an application has to be deployed on the vehicles which activates the front distance sensor. + * `VehicleHeadways` - Obtain the headway towards the leading vehicle of each vehicle for each simulation step. To get this value, an application has to be deployed on the vehicles that activate the front distance sensor. * `DetectorFlow` - The flows of each subscribed induction loop. {{% alert note %}} -For using the detector flow type, inductions loops need to be configured in the SUMO and mapping configuration files (e.g. Highway tutorial). +For using the detector flow type, inductions loops need to be configured in the SUMO and mapping configuration files (e.g., Highway tutorial). {{% /alert %}} 2. `group-by`: The vehicles will be grouped by its vehicle type name (`VehicleType`), group they belong @@ -104,13 +104,14 @@ standard deviation based on biased sample variance for groups (in the short outp * Filtering by vehicle type. `VehicleType:Type` (e.g. `VehicleType:Car` to collect values only of vehicles of type "Car") * Filtering by time. `Time:From-To` (e.g. `Time:0-100` to collect values only of the first 100s of simulation time) -The following example will show an example of how you can specify the Statictics Output according to -your desired criteria. VehicleTravelTimes are the data we want to retrieve from vehicles and we want -to group vehicles by the abstract group we can define in mapping configuration file (see e.g. Barnim +The following example will show an example of how you can specify the Statistics Output according to +your desired criteria. +VehicleTravelTimes are the data we want to retrieve from vehicles. +We want to group vehicles by the abstract group we can define in the mapping configuration file (see e.g., Barnim scenario) and then calculate the average vehicle travel time value for each of these groups. ```xml - + VehicleTravelTimes VehicleGroup diff --git a/content/tutorials/barnim_develop_applications/_index.md b/content/tutorials/barnim_develop_applications/_index.md index 75a7db1b..e5929f19 100644 --- a/content/tutorials/barnim_develop_applications/_index.md +++ b/content/tutorials/barnim_develop_applications/_index.md @@ -23,7 +23,8 @@ used in the Barnim scenario. In this section, the actual source code used to cre After completing this tutorial you will be able to: * Develop Applications for simulation entities. -* Transmit and receive V2X-messages periodically or on request depending on the network type and communication mode (e.g. Topocast, Geobroadcast, etc.). +* Transmit and receive V2X-messages periodically or on request depending on the network type and communication mode ( +e.g. topologically-scoped unicast, geographically-scoped broadcast, etc.). * Calculate alternative routes to the destination to circumnavigate a road obstacle. {{% /alert %}} @@ -40,30 +41,32 @@ Applications can be mapped to various simulation entities, such as vehicles, ser ```java public class ExampleApp extends AbstractApplication implements VehicleApplication { -   -    @Override   -    public void onStartup() {   -    } -   -    @Override   -    public void onVehicleUpdated(VehicleData previousVehicleData, VehicleData updatedVehicleData) { -    }  -     -    @Override   -    public void processEvent(Event event){ -    }   -   -    @Override   -    public void onShutdown() {  -    } + + @Override + public void onStartup() { + } + + @Override + public void onVehicleUpdated(VehicleData previousVehicleData, VehicleData updatedVehicleData) { + } + + @Override + public void processEvent(Event event){ + } + + @Override + public void onShutdown() { + } } ``` -`onVehicleUpdated` needs to be defined and overwritten in order to successfully implement the interface `VehicleApplication`. `processEvent` handles all events that get called to the application specific event manager, like this: +`onVehicleUpdated` needs to be defined and overwritten in order to successfully implement the interface `VehicleApplication`. +`processEvent` handles all events that get called to the application specific event manager, like this: ```java getOperatingSystem().getEventManager().addEvent(new Event(getOperatingSystem().getSimulationTime(), this)); ``` -Some examples of events are shown below, but a more detailed description can be found in the [documentation](/docs/develop_applications/event_scheduling). +Some examples of events are shown below, but a more detailed description can be found in the +[documentation](/docs/develop_applications/event_scheduling). ## WeatherServer Application @@ -131,7 +134,10 @@ have the cellular module activated, will receive this message. ```java private Denm constructDenm() { final GeoCircle geoCircle = new GeoCircle(HAZARD_LOCATION, 3000.0D); - final MessageRouting routing = getOperatingSystem().getCellModule().createMessageRouting().geoBroadCast(geoCircle); + final MessageRouting routing = getOperatingSystem().getCellModule().createMessageRouting() + .broadcast() + .geographical(geoCircle) + .build(); final int strength = getOperatingSystem().getStateOfEnvironmentSensor(SENSOR_TYPE); @@ -199,9 +205,15 @@ private void reactOnEnvironmentData(SensorType type, int strength) { MessageRouting mr; if (useCellNetwork()) { - mr = getOperatingSystem().getCellModule().createMessageRouting().geoBroadCast(dest); + mr = getOperatingSystem().getCellModule().createMessageRouting() + .broadcast() + .geographical(dest) + .build(); } else { - mr = getOperatingSystem().getAdHocModule().createMessageRouting().geoBroadCast(dest); + mr = getOperatingSystem().getAdHocModule().createMessageRouting() + .broadcast() + .geographical(dest) + .build(); } Denm denm = new Denm(mr, new DENMContent( @@ -250,7 +262,7 @@ private void circumnavigateAffectedRoad(DENM denm, final String affectedRoadId) ReRouteSpecificConnectionsCostFunction myCostFunction = new ReRouteSpecificConnectionsCostFunction(); myCostFunction.setConnectionSpeedMS(affectedRoadId, denm.getCausedSpeed()); - INavigationModule navigationModule = getOperatingSystem().getNavigationModule(); + NavigationModule navigationModule = getOperatingSystem().getNavigationModule(); RoutingParameters routingParameters = new RoutingParameters().costFunction(myCostFunction); diff --git a/content/tutorials/tiergarten_communication/_index.md b/content/tutorials/tiergarten_communication/_index.md index 063a678a..e879dfb9 100644 --- a/content/tutorials/tiergarten_communication/_index.md +++ b/content/tutorials/tiergarten_communication/_index.md @@ -149,8 +149,8 @@ are received and written to the log file by the `MessageReceivingApp` applicatio ### Receiving the V2X messages First, we start -off with the class definition of the `MessageReceivingApp`, which is mapped onto the vehicles, and then we will run through the methods we have to implement in order -to get the communication working. +off with the class definition of the `MessageReceivingApp`, which is mapped onto the vehicles, +and then we will run through the methods we have to implement in order to get the communication working. #### Class definition @@ -278,7 +278,12 @@ closer look at the `sendAdHocBroadcast()` method we defined in the `TiergartenRS ```java private void sendAdHocBroadcast() { - final MessageRouting routing = getOs().getAdHocModule().createMessageRouting().viaChannel(AdHocChannel.CCH).topoBroadCast(); + final MessageRouting routing = getOs().getAdHocModule().createMessageRouting() + .channel(AdHocChannel.CCH) + .broadcast() + .topological() + .singlehop() + .build(); final InterVehicleMsg message = new InterVehicleMsg(routing, getOs().getPosition()); getOs().getAdHocModule().sendV2xMessage(message); } @@ -288,8 +293,9 @@ This method has basically three tasks to solve: * Firstly, a routing description has to be created, which defines the communication type, the source and destination for the message, and additional properties like the maximum number of hops and the communication channel. In this specific case, - `topoBroadcast(AdHocChannel.CCH)` creates a message routing which includes the IP address of the *RSU* as the source, - the broadcast address as the destination, and a communication path using the present ad-hoc topology with only one hop. + the `AdHocMessageRoutingBuilder` creates a message routing which includes the IP address of the *RSU* as the source, + the broadcast address as the destination (`.broadcast()`), and a communication path using the present ad-hoc topology (`.topological()`) + with only one hop (`.singlehop()`). * Secondly, the message to be send is created. The previously created message routing description is passed to this custom *V2X* message. * Finally, the message is send using the ad-hoc module of the *RSU*. @@ -381,7 +387,8 @@ mosaic.bat -s Tiergarten Afterwards, in the log directory of `Eclipse MOSAIC` a new folder should be created containing all log files of the simulation run. Within, the sub-folder `apps` contains the log files for each simulation unit and its application. -For example, for the normal vehicles we end up with three log files: `MessageReceivingApp.log`, `EventSendingApp.log` and `EventProcessingApp.log`. +For example, for the normal vehicles we end up with three log files: `MessageReceivingApp.log`, `EventSendingApp.log` +and `EventProcessingApp.log`. This following snippet shows the receiving of the V2X messages that were sent by the RSU: diff --git a/content/workshops/_index.md b/content/workshops/_index.md new file mode 100644 index 00000000..6d546185 --- /dev/null +++ b/content/workshops/_index.md @@ -0,0 +1,18 @@ +--- +title: MOSAIC Workshops +layout: docs +toc: false + +# Optional header image (relative to `static/img/` folder). +header: + caption: "" + image: "" +--- + +Join our hands-on Workshops to master Eclipse MOSAIC and MOSAIC Extended! In these interactive sessions, you will learn both the fundamentals and advanced knowledge through practical exercises and real-time guidance from our experienced instructors. + +Each workshop focuses on various aspects and functionalities of Eclipse MOSAIC and MOSAIC Extended, empowering you to create everything from simple to complex simulation scenarios tailored to your specific needs. You'll have the opportunity to develop applications and configure detailed aspects of your simulations in a collaborative environment. + +If you are interested in a MOSAIC Workshop please leave us a message at mosaic@fokus.fraunhofer.de and we will create an individual offer suitable to your needs. + +{{< menu_overview workshops >}} diff --git a/content/workshops/electric_vehicle/_index.md b/content/workshops/electric_vehicle/_index.md new file mode 100644 index 00000000..808c8430 --- /dev/null +++ b/content/workshops/electric_vehicle/_index.md @@ -0,0 +1,29 @@ +--- +title: Workshop Electric Vehicle +categories: + - Workshop +linktitle: workshop_electric_vehicle +toc: false +type: workshops +draft: false +pagination_prev: parking_observer +--- + +The increasing adoption of electric vehicles (EVs) presents unique challenges and opportunities for optimizing travel efficiency. This workshop aims to explore the journey optimization of an electric vehicle traveling from Berlin to Rostock, focusing on effective charging strategies and route planning. Participants will engage in exercises designed to enhance their understanding of EV charging dynamics and improve travel time while maintaining battery health. + +**Base Scenario** \ +The workshop centers around a simulated journey of an electric vehicle with a limited battery range from Berlin to Rostock, a distance of approximately 230 km. The EV starts with a specific battery charge level and must navigate the route while identifying charging points to ensure it never drops below a critical charge level of 5%. The scenario involves evaluating various charging station options, including fast chargers, and optimizing the travel time by considering charging durations and station availability. + +{{< figure src="images/charging-stations.png" width="400" title="Possible charging stations" >}} + +**Exercise I: Search Reactively** \ +Implement a reactive search mechanism that triggers when the EV's battery charge drops below 20%. The system should identify nearby charging stations within a 5 km radius of the current location, ensuring that the vehicle does not reach a charge level below 5%. + +**Exercise II: Optimize Total Travel Time** \ +Develop an optimization algorithm that calculates the most efficient travel route to Rostock by evaluating charging options. This includes prioritizing quick chargers with 100 kW+ capability and assessing their availability along the route to minimize overall travel time. + +**Exercise III: Reserve Charging Station** \ +Create a proactive reservation system that allows the driver to book a charging station at the start of the journey. This system should consider the estimated time of arrival at each charging station and ensure that the selected station has the necessary charging capacity available. + +**Conclusion** \ +By the end of the workshop, participants will have gained practical experience in journey optimization for electric vehicles. They will learn how to implement reactive and proactive charging strategies, assess the impact of charging station availability on travel time, and develop algorithms to enhance the overall efficiency of EV travel. This knowledge will empower participants to make informed decisions regarding EV route planning and charging management in real-world applications. \ No newline at end of file diff --git a/content/workshops/electric_vehicle/images/charging-stations.png b/content/workshops/electric_vehicle/images/charging-stations.png new file mode 100644 index 00000000..3c530d93 Binary files /dev/null and b/content/workshops/electric_vehicle/images/charging-stations.png differ diff --git a/content/workshops/electric_vehicle/images/menu.png b/content/workshops/electric_vehicle/images/menu.png new file mode 100644 index 00000000..45876822 Binary files /dev/null and b/content/workshops/electric_vehicle/images/menu.png differ diff --git a/content/workshops/future/images/menu.png b/content/workshops/future/images/menu.png new file mode 100644 index 00000000..c09d7322 Binary files /dev/null and b/content/workshops/future/images/menu.png differ diff --git a/content/workshops/maintenance_car/_index.md b/content/workshops/maintenance_car/_index.md new file mode 100644 index 00000000..922248d3 --- /dev/null +++ b/content/workshops/maintenance_car/_index.md @@ -0,0 +1,31 @@ +--- +title: MOSAIC 101 - Workshop Maintenance Car +categories: + - Workshop +linktitle: workshop_maintenance_car +toc: false +type: workshops +draft: false +#pagination_next: future +--- + +The Eclipse MOSAIC workshops provide participants with an opportunity to engage in hands-on learning experiences focused on vehicle simulation and traffic management. The workshops are structured into three main exercises, each building upon the previous one to enhance understanding and practical skills. + +**Base Scenario** \ +Initially, participants will explore a basic scenario where commuters travel along Prenzlauer Allee in Berlin. They will observe how traffic flows without interruptions, setting the stage for more complex interactions. + +{{< figure src="images/overview.png" width="500px" >}} + +**Exercise I: Understanding Vehicle Behavior** \ +In the first exercise, participants will execute a simulation scenario and observe how vehicles respond to a breakdown. They will learn how to configure vehicle behavior by mapping applications onto vehicles, and thereby improve traffic efficiency. +The exercise introduces the concept of vehicles slowing down when encountering a breakdown and how some vehicles can reroute to avoid the affected area. + +**Exercise II: Exploring Communication** \ +The second exercise focuses on communication between vehicles. Participants will learn how vehicles can notify an emergency server about breakdowns, allowing other vehicles to receive important information and adjust their routes accordingly. This exercise emphasizes the importance of communication in enhancing traffic flow and safety. + +**Exercise III: Impelementing Driving Behaviour** \ +Participants will create a maintenance vehicle that responds to the breakdown, navigates through traffic, and assists in the repair. +The final exercise integrates all the knowledge gained from previous sessions, and this exercise showcases the practical application of simulation concepts in real-world scenarios. + +**Conclusion** \ +Through these workshops, participants will gain valuable insights into vehicle behavior, communication, and traffic management. By the end of the series, they will be equipped with practical skills to create and manage complex simulation scenarios effectively, enhancing their understanding of modern traffic systems. \ No newline at end of file diff --git a/content/workshops/maintenance_car/images/menu.png b/content/workshops/maintenance_car/images/menu.png new file mode 100644 index 00000000..8351a75c Binary files /dev/null and b/content/workshops/maintenance_car/images/menu.png differ diff --git a/content/workshops/maintenance_car/images/overview.png b/content/workshops/maintenance_car/images/overview.png new file mode 100644 index 00000000..f984db7b Binary files /dev/null and b/content/workshops/maintenance_car/images/overview.png differ diff --git a/content/workshops/parking_observer/_index.md b/content/workshops/parking_observer/_index.md new file mode 100644 index 00000000..268922c0 --- /dev/null +++ b/content/workshops/parking_observer/_index.md @@ -0,0 +1,34 @@ +--- +title: Workshop Parking Observer +categories: + - Workshop +linktitle: workshop_parking_observer +toc: false +type: workshops +draft: false +pagination_prev: maintenance_car +pagination_next: electric_vehicle +--- + +{{% alert note %}} +Rework thoroughly after slides are done +{{% /alert %}} + +The participants will work on a mobility service aimed at detecting parking offenders using connected vehicles. + +**Base Scenario** \ +Describe the scenario in some few sentences. + +{{< figure src="images/parking-offender.png" >}} + +**Exercise I: Understanding the Sensor Module** \ +Explain the Sensor Module in some few sentences. + +**Exercise II: Fix Something** \ +Fix issues with vehicle communication and sensor calibration. + +**Exercise III: Visualize and Identify Parking Offenders** \ +Uncover the hidden message left by parking offenders. + +**Conclusion** \ +The participants successfully detect parking offenders and enhance the mobility service. diff --git a/content/workshops/parking_observer/images/menu.png b/content/workshops/parking_observer/images/menu.png new file mode 100644 index 00000000..c4d35cc2 Binary files /dev/null and b/content/workshops/parking_observer/images/menu.png differ diff --git a/content/workshops/parking_observer/images/parking-offender.png b/content/workshops/parking_observer/images/parking-offender.png new file mode 100644 index 00000000..1ab41efc Binary files /dev/null and b/content/workshops/parking_observer/images/parking-offender.png differ diff --git a/themes/academic/assets/scss/mosaic.scss b/themes/academic/assets/scss/mosaic.scss index 8e2bfb69..085786ed 100644 --- a/themes/academic/assets/scss/mosaic.scss +++ b/themes/academic/assets/scss/mosaic.scss @@ -310,3 +310,7 @@ span.page_with_curl { text-shadow: 0 1px 2px #44083b; padding-top: 0px; } + +.inactive { + color: #8a8a8a; +} diff --git a/themes/academic/layouts/_default/list.html b/themes/academic/layouts/_default/list.html index ead6ac28..83afeb35 100644 --- a/themes/academic/layouts/_default/list.html +++ b/themes/academic/layouts/_default/list.html @@ -31,6 +31,7 @@

{{ .Title }}

{{ partial "pagination" . }} {{ partial "tutorial_pagination" . }} + {{ partial "workshop_pagination" . }} {{- end -}} diff --git a/themes/academic/layouts/partials/site_head.html b/themes/academic/layouts/partials/site_head.html index f88cda76..c27c43b2 100644 --- a/themes/academic/layouts/partials/site_head.html +++ b/themes/academic/layouts/partials/site_head.html @@ -8,15 +8,15 @@ base-uri 'self'; default-src 'none'; object-src 'none'; - script-src 'self' 'unsafe-inline' 'unsafe-eval' https://*.fokus.fraunhofer.de https://*.dcaiti.tu-berlin.de https://eclipse.dev https://www.eclipse.dev https://code.jquery.com https://cdn.jsdelivr.net https://maps.google.com https://cse.google.com ; - worker-src 'self' https://*.fokus.fraunhofer.de https://*.dcaiti.tu-berlin.de https://eclipse.dev https://www.eclipse.dev https://code.jquery.com https://cdn.jsdelivr.net https://maps.google.com https://cse.google.com ; - style-src 'self' 'unsafe-inline' https://*.fokus.fraunhofer.de https://*.dcaiti.tu-berlin.de https://eclipse.dev https://www.eclipse.dev https://cdn.jsdelivr.net ; - img-src 'self' data: https://*.fokus.fraunhofer.de https://*.dcaiti.tu-berlin.de https://eclipse.dev https://www.eclipse.dev ; - media-src 'self' data: https://*.fokus.fraunhofer.de https://*.dcaiti.tu-berlin.de https://eclipse.dev https://www.eclipse.dev ; - font-src 'self' data: https://*.fokus.fraunhofer.de https://*.dcaiti.tu-berlin.de https://eclipse.dev https://www.eclipse.dev ; - child-src https://*.fokus.fraunhofer.de https://*.dcaiti.tu-berlin.de https://eclipse.dev https://www.eclipse.dev https://*.dcaiti.com https://dcaiti.com https://cse.google.com ; - connect-src https://*.fokus.fraunhofer.de https://*.dcaiti.tu-berlin.de https://eclipse.dev https://www.eclipse.dev http://localhost:1313/ ws://localhost:1313/ ; - manifest-src 'self' https://*.fokus.fraunhofer.de https://*.dcaiti.tu-berlin.de https://maps.google.com https://cse.google.com https://play.google.com ; + script-src 'self' 'unsafe-inline' 'unsafe-eval' https://*.dcaiti.tu-berlin.de https://eclipse.dev https://www.eclipse.dev https://code.jquery.com https://cdn.jsdelivr.net https://maps.google.com https://cse.google.com ; + worker-src 'self' https://*.dcaiti.tu-berlin.de https://eclipse.dev https://www.eclipse.dev https://code.jquery.com https://cdn.jsdelivr.net https://maps.google.com https://cse.google.com ; + style-src 'self' 'unsafe-inline' https://*.dcaiti.tu-berlin.de https://eclipse.dev https://www.eclipse.dev https://cdn.jsdelivr.net ; + img-src 'self' data: https://*.dcaiti.tu-berlin.de https://eclipse.dev https://www.eclipse.dev ; + media-src 'self' data: https://*.dcaiti.tu-berlin.de https://eclipse.dev https://www.eclipse.dev ; + font-src 'self' data: https://*.dcaiti.tu-berlin.de https://eclipse.dev https://www.eclipse.dev ; + child-src https://*.dcaiti.tu-berlin.de https://eclipse.dev https://www.eclipse.dev https://*.dcaiti.com https://dcaiti.com https://cse.google.com ; + connect-src https://*.dcaiti.tu-berlin.de https://eclipse.dev https://www.eclipse.dev http://localhost:1313/ ws://localhost:1313/ ; + manifest-src 'self' https://*.dcaiti.tu-berlin.de https://maps.google.com https://cse.google.com https://play.google.com ; frame-ancestors 'self'; "> diff --git a/themes/academic/layouts/partials/workshop_pagination.html b/themes/academic/layouts/partials/workshop_pagination.html new file mode 100644 index 00000000..77355687 --- /dev/null +++ b/themes/academic/layouts/partials/workshop_pagination.html @@ -0,0 +1,23 @@ +{{ if (eq .Params.type "workshops") }} +
+
+ + {{/* Previous workshop */}} +
+ {{ range (where .Site.Menus.workshops "Identifier" .Params.pagination_prev) }} +
{{ i18n "previous" }}
+ + {{ end }} +
+ + {{/* Previous workshop */}} +
+ {{ range (where .Site.Menus.workshops "Identifier" .Params.pagination_next) }} +
{{ i18n "next" }}
+ + {{ end }} +
+ +
+
+{{ end }} diff --git a/themes/academic/layouts/shortcodes/menu_overview.html b/themes/academic/layouts/shortcodes/menu_overview.html index fc389471..b9366bf3 100644 --- a/themes/academic/layouts/shortcodes/menu_overview.html +++ b/themes/academic/layouts/shortcodes/menu_overview.html @@ -4,7 +4,11 @@ {{ range $index, $menuItem := (index .Site.Menus $menuName) }} {{ $counter := add $index 1 }}
  • + {{- with $menuItem.URL -}} + {{- else -}} + + {{- end -}} {{ $counter }}.  {{ $menuItem.Name }} @@ -14,9 +18,11 @@ {{- . | markdownify -}} {{- end -}} + {{- with $menuItem.URL -}} Learn more + {{- end -}}
    • {{ end }}