Allow trigger stops by current battery charge

[palvarezlopez]

If a vehicle with electric device stops in a charging station, only leave it if battery charge is (for example) 80%

[namdre]

might be added via new parameters for device.battery to allow battery management:

• trigger management when battery level drops below a given value
• add stops when passing a chargingStation
• reroute to add detour to chargingStation

Mostly useful for vehicles that stay in the simulation without a predefined route (taxi/DRT). In contrast, Vehicles running on a public transport schedule should fit battery management into their regular schedule.

[yunpangfloetteroed]

Hi. The attached ist the basic process concept for seraching charging station and charging E-vehicles, prepared by Pablo, Micha and me. Any comments are welcome. The implementation work is planned to begin at the end of May.

[yunpangfloetteroed]

Another ticket is open for defining the necessary attributes, #13294

[namdre]

Since this is new and complex behavior which probably isn't useful to all users of the battery device, I think it would be better to put this into a new device (i.e. BatteryManager). The new device can easily check the current / total battery level and plan accordingly. Further advantages:

• avoids cluttering the BatteryDevice will a ton of new parameters
• can be combined with ElecHybrid as well

[yunpangfloetteroed]

I like the idea with batteryManager. We may need to re-arrange the attributes in the batterDevice. Some of the current attributes, e.g. energyConsumed, in a battery device could move to batteryManager...

[namdre]

No. everything that is currently in the battery needs to stay there since the device must continue to work without a battery manager. The manager only monitors the state and adapts vehicle behavior for automatic charging.

[behrisch]

I would propose a new name for the manager: stationFinder. This is agnostic of the fuel type (because we may want to use it for finding gas stations as well) and describes the main functionality better. @namdre @yunpangfloetteroed @palvarezlopez opinions?

[yunpangfloetteroed]

agree

[namdre]

@yunpangfloetteroed If the stationFinder requires some KPIs which are currently not tracked by the battery device, they should probably be stored in the stationFinder (by retrieving data via the existing API of the battery device). If the KPIs are deemed generally useful we might also add them to the battery device direclty.

[yunpangfloetteroed]

Yes!

[yunpangfloetteroed]

I updated the process concept above according to our discussion and the attributes we defined.

[m-kro]

How to integrate a little more long-term view than searching for a last-resort charging opportunity? If (working) days and trip chains are simulated, more conditions and constraints would become important:

• target SoC at the end of the trip (e.g. start the next day with a full battery)
• type of charging station (prefer slow/fast charging, bidirectional charging acceptance)
• time constraints less important at the last stop ~ "home"? (especially for bidirectional charging)
• detour length: (walking) distance between actual stop and charging station (~ can the stop at the charging station replace the actual stop partially?)

Additionally, I suggest to add weight factors to the selection index components to switch some off if wanted. This would make it possible as well to value the importance of time.

trip chains: I have modeled trip chains as a single trip in SUMO because I don't need explicit persons. Stops define the origins/destinations.

[namdre]

Additionally, I suggest to add weight factors to the selection index components to switch some off if wanted. This would make it possible as well to value the importance of time.

It might be useful to re-purpose some code/ideas from the parking search (https://sumo.dlr.de/docs/Simulation/Rerouter.html#determining_the_alternative_parking_area

[yunpangfloetteroed]

Just in case that no historical energy per unit is available, e.g. a vehicle starts with a very low SoC and searches a charging station right after entering the network, the empirical energy consumption average 200 Wh/km will be used for calculating E_est (this is added in the diagram above).

[m-kro]

Is the current unit for E_est W/s in the flow chart right? W is already defined as J/s. I think this should be just W...

[m-kro]

Feature request: Deactivate the device temporarily (e.g. by TraCI) to end an important trip such as a taxi ride of a passenger.

[m-kro]

Additional feature: inspect planned stops (from other sources, e.g. predefined in XML) for charging stations and eventually let the vehicle proceed if it is estimated to make it there.

[m-kro]

Added a parameter device.stationfinder.maxEuclideanDistance to limit the search for charging stations spatially. This is needed for large networks / networks with a lot of charging stations because ranking them all by travel time needs too much computation time.

[m-kro]

Some more ideas:

• optionally set a target SoC / a maximum charging duration
• optionally set a threshold when the charging stop shall replace a planned stop close by (or take some stopping time off from the other stop)

Now that the target function for parking search has been adapted to charging stations (see #14504), more options arise:

• charging station preference (private / public charging)
• distance from/to next stop can be introduced in the target function simply by setting the respective weight to a value > 0
• ...