feat(charging): provide the charging stations within a certain area #446

kschrab · 2024-12-12T10:42:22Z

Description

What is this PR about?

Issue(s) related to this PR

Resolves issue # / internal issue

Affected parts of the online documentation

Changes in the documentation required?

Definition of Done

Prerequisites

You have read CONTRIBUTING.md carefully.
You have signed the Contributor License Agreement.
Your GitHub user id is linked with your Eclipse Account.

Required

The title of this merge request follows the scheme type(scope): description (in the style of Conventional Commits)
You have assigned a suitable label to this pull request (e.g., enhancement, or bugfix)
origin/main has been merged into your Fork.
Coding guidelines have been followed (see CONTRIBUTING.md).
All checks on GitHub pass.
All tests on Jenkins pass.

Requested (can be enforced by maintainers)

New functionality is covered by unit tests or integration tests. Code coverage must not decrease.
If a bug has been fixed, a new unit test has been written (beforehand) to prove misbehavior
There are no new SpotBugs warnings.

Special notes to reviewer

hoelger · 2024-12-12T16:06:24Z

...n/java/org/eclipse/mosaic/fed/application/ambassador/util/EventNicenessPriorityRegister.java

@@ -46,4 +46,7 @@ public class EventNicenessPriorityRegister {

    // batteryUpdated
    public final static long BATTERY_UPDATED = -99_998_900;
+
+    // discover charging stations
+    public final static long CHARGING_STATIONS_DISCOVERY = -99_998_900;


Can somebody explain me at which point the "niceness" is required? What is the effect of this priorization and why do we need it and don't go with FCFS?

Why do we use this only sometimes (in process(final EnvironmentSensorUpdates environmentSensorUpdates) it's not used)

@kschrab @schwepmo

AFAIK, our DefaultEventScheduler doesn't care about the niceness of an event.
It uses a PriorityQueue using the time as priority. If there a ties, i.e. same execution time, Events are executed in an arbitrary order. I think ideally, we would use the defined niceness values to deterministically break those ties.

In the (highly unstable) MultiThreadedEventScheduler the niceness value is actually used. However, I'm not certain if it has any effect there.

So yes, we don't use this properly anyhow, but if we would it would be to break ties (I think)

@iwillitried for this reason the value of CHARGING_STATIONS_DISCOVERY should probably be unique.

hoelger · 2024-12-12T16:09:54Z

...n/java/org/eclipse/mosaic/fed/application/ambassador/util/EventNicenessPriorityRegister.java

@@ -46,4 +46,7 @@ public class EventNicenessPriorityRegister {



Why is only the first number positive, but then we count from strong negative upwards.

In other words: I do not understand, if the VEHICLE_ADDED or the UNIT_REMOVED is the message with the highest priority, as both are at the "border" of that Zahlenstrahl

@kschrab @schwepmo

hoelger · 2024-12-12T16:14:51Z

.../main/java/org/eclipse/mosaic/interactions/electricity/ChargingStationDiscoveryResponse.java

+
+    @Override
+    public int hashCode() {
+        return new HashCodeBuilder(9, 97)


What are those magic numbers here?

Those are the seeds for the hash function. Refer to the Apache Documentation for more insights :)

Please remove magic numbers, e.g.

// seeds: hard-coded, randomly chosen, non-zero, odd number final static int INITIAL_ODD_NUMBER= 9; final static int MULTIPLIER_ODD_NUMBER = 97; return new HashCodeBuilder(INITIAL_ODD_NUMBER, MULTIPLIER_ODD_NUMBER);

I don't think this is necessary. At least we don't typically do it when overriding the hashCode function.

Probably the most sensible solution would be to use the default constructor of HashCodeBuilder, which uses 37 and 17 by default.

(see https://commons.apache.org/proper/commons-lang/apidocs/src-html/org/apache/commons/lang3/builder/HashCodeBuilder.html#line-505)

hoelger · 2024-12-12T16:22:22Z

...java/org/eclipse/mosaic/interactions/electricity/VehicleChargingStationDiscoveryRequest.java

+    }
+
+    @Serial
+    private static final long serialVersionUID = 1L;


Why do we have the serial number here? If it's an interaction-specific thing, why don't we use it in the response as well?

Interaction implements Serializable, if we would do distributed simulation in some way or another and serialize/deserialize interactions between remote hosts, this UID would be used to assure that all sides have the same class version loaded. When adding new Interactions giving a serialVersionUID of 1 is good, indicating version 1.

Now what we should consider though is that we update this ID whenever we change Interactions in a meaningful manner.

(see https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/Serializable.html)

I hope this suffices as a explanation 😅

schwepmo · 2024-12-16T11:28:14Z

...ation/src/main/java/org/eclipse/mosaic/fed/application/ambassador/ApplicationAmbassador.java

I think instead of adding the new ChargingStationDiscoveryResponse interaction. We could/should handle the querying of Charging Stations similar to that of traffic lights (see line 370). Though instead of requiring enabled perception, we assume that EVs have access to a static map of all charging stations.

At least this is how I understood the intention of @kschrab.

schwepmo · 2024-12-17T10:28:10Z

.gitignore

+.tiles
+/logs/


This should not be necessary, please remove

schwepmo · 2024-12-17T10:28:44Z

.../main/java/org/eclipse/mosaic/fed/application/ambassador/simulation/ElectricVehicleUnit.java

@@ -63,6 +75,11 @@ protected boolean handleEventResource(Object resource, long eventType) {
            return true;
        }

+        if (resource instanceof ChargingStationDiscoveryResponse response) {
+            onCharginStationDiscoveryResponse((ChargingStationDiscoveryResponse) response);


This cast is not necessary

Suggested change

onCharginStationDiscoveryResponse((ChargingStationDiscoveryResponse) response);

onCharginStationDiscoveryResponse(response);

schwepmo · 2024-12-17T10:39:59Z

...java/org/eclipse/mosaic/interactions/electricity/VehicleChargingStationDiscoveryRequest.java

+    }
+
+    @Serial
+    private static final long serialVersionUID = 1L;


Interaction implements Serializable, if we would do distributed simulation in some way or another and serialize/deserialize interactions between remote hosts, this UID would be used to assure that all sides have the same class version loaded. When adding new Interactions giving a serialVersionUID of 1 is good, indicating version 1.

Now what we should consider though is that we update this ID whenever we change Interactions in a meaningful manner.

(see https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/Serializable.html)

I hope this suffices as a explanation 😅

schwepmo · 2024-12-17T10:42:18Z

.../main/java/org/eclipse/mosaic/interactions/electricity/ChargingStationDiscoveryResponse.java

+
+    @Override
+    public int hashCode() {
+        return new HashCodeBuilder(9, 97)


I don't think this is necessary. At least we don't typically do it when overriding the hashCode function.

Probably the most sensible solution would be to use the default constructor of HashCodeBuilder, which uses 37 and 17 by default.

schwepmo · 2024-12-17T10:43:16Z

.../main/java/org/eclipse/mosaic/interactions/electricity/ChargingStationDiscoveryResponse.java

+
+    @Override
+    public int hashCode() {
+        return new HashCodeBuilder(9, 97)


(see https://commons.apache.org/proper/commons-lang/apidocs/src-html/org/apache/commons/lang3/builder/HashCodeBuilder.html#line-505)

schwepmo · 2024-12-17T10:48:44Z

.../main/java/org/eclipse/mosaic/fed/application/app/api/os/ElectricVehicleOperatingSystem.java

+     *
+     * @param searchArea The area where the charging stations are search
+     */
+    void sendChargingStationDiscoveryRequest(GeoCircle searchArea);


We should probably define the search area as a GeoArea.

Suggested change

void sendChargingStationDiscoveryRequest(GeoCircle searchArea);

void sendChargingStationDiscoveryRequest(GeoArea searchArea);

Furthermore, we should also discuss what signatures are relevant.
I can think of:

getClosestChargingStation(GeoPosition position) & getClosestChargingStation() -> returns the closest charging station either to the current position of the vehicle or to a specified position. E.g., when running low on battery.

Here we should also consider if we just want to consider spatial proximity or also the travel time. As charging stations at the opposite direction of a highway can actually be quite far -> getShortestPathChargingStation(...)

getChargingStationsInArea(GeoArea geoArea) -> your use case

getChargingStationsWithinRange(double distance) -> Get all charging stations that can be reached within a distance

getChargingStationsAlongRoute(double maxDetour) -> Get all charging stations that are located along the route. This requires advanced routing though.

provide the charging stations within a certain area

e934a58

hoelger suggested changes Dec 12, 2024

View reviewed changes

schwepmo reviewed Dec 16, 2024

View reviewed changes

schwepmo requested changes Dec 17, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(charging): provide the charging stations within a certain area #446

feat(charging): provide the charging stations within a certain area #446

kschrab commented Dec 12, 2024

hoelger Dec 12, 2024

hoelger Dec 12, 2024

schwepmo Dec 16, 2024

hoelger Dec 12, 2024

hoelger Dec 12, 2024

iwillitried Dec 16, 2024

hoelger Dec 16, 2024 •

edited

Loading

schwepmo Dec 17, 2024

schwepmo Dec 17, 2024

hoelger Dec 12, 2024

schwepmo Dec 17, 2024

schwepmo Dec 16, 2024

schwepmo Dec 17, 2024

schwepmo Dec 17, 2024

schwepmo Dec 17, 2024

schwepmo Dec 17, 2024

schwepmo Dec 17, 2024

schwepmo Dec 17, 2024

		@@ -46,4 +46,7 @@ public class EventNicenessPriorityRegister {

	onCharginStationDiscoveryResponse((ChargingStationDiscoveryResponse) response);
	onCharginStationDiscoveryResponse(response);

	void sendChargingStationDiscoveryRequest(GeoCircle searchArea);
	void sendChargingStationDiscoveryRequest(GeoArea searchArea);

		.tiles
		/logs/

feat(charging): provide the charging stations within a certain area #446

Are you sure you want to change the base?

feat(charging): provide the charging stations within a certain area #446

Conversation

kschrab commented Dec 12, 2024

Description

Issue(s) related to this PR

Affected parts of the online documentation

Definition of Done

Special notes to reviewer

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hoelger Dec 16, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hoelger Dec 16, 2024 •

edited

Loading