Open palvarezlopez opened 2 years ago
might be added via new parameters for device.battery to allow battery management:
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.
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.
Another ticket is open for defining the necessary attributes, #13294
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:
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...
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.
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?
agree
@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.
Yes!
I updated the process concept above according to our discussion and the attributes we defined.
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:
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.
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
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).
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...
Feature request: Deactivate the device temporarily (e.g. by TraCI) to end an important trip such as a taxi ride of a passenger.
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.
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.
Some more ideas:
Now that the target function for parking search has been adapted to charging stations (see #14504), more options arise:
If a vehicle with electric device stops in a charging station, only leave it if battery charge is (for example) 80%