Simulating arbitrary drt service tasks, e.g. maintenance #3485
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Within my parental leave I started the development of a drt contribution (called services) that allows a flexible and extensible definition, dispatching and scheduling of so-called service tasks. Especially, the operation of AD (autonomous driven) drt services brings tasks, such as cleaning, maintenance, plug-in/out into the focus of operations. Even certain weather events that requires the short-dated grounding of the whole fleet may be a very interesting topic for a fleet simulation that could be now stimulated. The main motivation for this concept was the question of how much staff needs to be allocated at hubs/depots to handle a fleet of several hundred vehicles.
The approach
Drt services get extended by an optional parameter set ‘DrtServicesParams’
The ‘DrtServicesParams’ describes sets of services ‘DrtServiceParams’, such as cleaning, sensor checks.
Each service has at least a duration, execution limit and may be attached (stacked to a charging task)
To plan a service ‘DrtServiceParams’ one need to add so called triggers. There are already example triggers, such as Stop, Mileage or Charging triggers. A trigger describes a specific condition under which a service tasks gets scheduled. E.g. if the vehicle has traveled 250 km or it has realized 50 stops a certain service tasks will be scheduled. A charging trigger will execute a defined service task while charging. By setting the service parameter ‘enableTaskStacking=true’ the existing charging time will be utilized for the attached service task. If this time is consumed, the remaining service time is appended to the schedule. The contribution is shipped with some service profile plots and service execution csv. The service profiles allows to estimate the required total staff to handle all service/maintenance tasks at hubs. The approach supports till now drt and edrt. By design it requires the definition of operation facilities (hubs), as those hubs are used to execute service tasks. Ressource constrains, such as available staff at a hub, is not yet implemented, but could be added later on.