In an upcoming PR we want to implement peer-to-peer car-sharing in the shared_mobility contrib. The idea is that vehicle owners can either share with other individuals or contribute their (automated) vehicle temporarily to a managed fleet. Technically, this means that we temporarily integrate new vehicles into a DVRP/DRT fleet. This works without a problem with DVRP and DRT: We just override a new Fleet implementation that allows adding and removing vehicles on the fly. Everything works surprisingly smoothly, only the analysis code makes certain assumptions that are not compatible with a dynamic fleet.

Therefore, we would like to propose flexibilizing the analysis with the following steps:

• Introduce an AbstractFleetEvent in DVRP with two specific implementations VehicleAddedEvent and VehicleRemovedEvent
• Modify the analysis packages in DVRP and DRT such that they detect these events
• Instead of having one VehicleState for each vehicle to track the activity, we introduce a list of states because vehicles can be active during multiple periods of the day

What do you think about that? Is this something that sounds interesting or should we find another solution? @michalmac

There is one design decision we are unsure about. Currently, handling the fleet is managed differently in DVRP and DRT:

• DRT takes a FleetDefinition when initializing the analysis components and then responds to events linked to those vehicle IDs
• DVRP tracks TaskStartEvents and registers vehicles for analysis once they find a task with the right DVRP mode and task index = 0

We could replace this logic by publishing a VehicleAddedEvent by default at the beginning of the iteration and then respond to it in both cases. But this is not fully necessary, we can just treat added vehicles as a special case.