Introduction

Private car ownership has grown relentlessly since the post-war boom, reaching an estimated 1.5 billion vehicles worldwide in 20241. Europe averages 570 cars per 1,000 inhabitants, and countries such as Italy already exceed 6802. These vehicles are chronically under-utilised, remaining parked for roughly 95% of the time3,4. The environmental and social costs are substantial: private cars account for about one quarter of global road-transport \(\mathrm {CO_2}\) emissions5,6, occupy valuable curb space and aggravate congestion, which in turn lengthens travel times and degrades urban air quality7,8.

In response to these challenges, municipal and regional authorities have proposed various interventions, including reduced speed limits, congestion pricing, and incentives for multimodal travel9,10,11. At the European Union level, the ban on new internal-combustion cars from 2035 aims to accelerate electric-vehicle (EV) adoption 9. These measures, however, focus on tail-pipe emissions rather than on the absolute size of the car fleet12,13. Even widespread electrification, indeed, would leave cars largely unused and introduce battery life and resource intensity issues14,15.

Shared Mobility on Demand (MoD) services offer an alternative to individual ownership, yet today’s free-floating car-sharing services offer flexibility but come with their own set of inefficiencies, including high operational costs and the need for large fleets that can compound congestion issues16. Integrating autonomous driving technology into MoD frameworks could unlock higher utilisation and lower costs17,18,19. Industry initiatives by Waymo, Cruise, and Tesla demonstrate rapid progress, but the leap to fully driverless robotaxi fleets still faces complex regulations, especially in Europe, strict safety certification, and formidable real-time computing requirements20,21.

Hence, while a fully Autonomous Mobility on Demand (AMoD) model remains the long-term goal, intermediate solutions that are easier to deploy and regulate deserve investigation.

Fig. 1
figure 1

Conceptual diagram of the valet-style AMoD service. Reading from left to right: the autonomous vehicle navigates itself (empty) to the requested trip origin. Once it arrives, the user boards and drives the vehicle manually to the destination. After the user leaves the vehicle, it proceeds autonomously to its next task: picking up another passenger, recharging, or parking.

Full size image

An intermediate approach, the valet-style AMoD model, schematically depicted in Fig. 1, has recently attracted industrial interest, yet academic work on halfway-autonomous services remains sparse: to our knowledge only one study has explored a comparable semi-autonomous solution, and then solely for last-mile service in urban areas22, underscoring how open this research avenue still is. This study is part of a broader research initiative carried out by our research group within the AIDA project (Artificial Intelligence Driving Autonomous)23, one of Italy’s flagship programs on autonomous mobility. In this context, a valet-style AMoD service is being prototyped and field-tested in real urban settings. AIDA develops a transitional model of autonomy, different from fully driverless robotaxi solutions, where vehicles navigate empty at low speed to the customers, who then drive manually to the destination; after drop-off, the car either repositions to another customer, parks kerbside, or reaches a charging hub. Remote supervisors handle rare edge cases via low-bandwidth 4G connections, avoiding full tele-operation and reducing technical complexity. Because autonomy is limited to low-speed positioning, the valet approach can be a way to circumvent many of the regulatory and technical hurdles faced by fully autonomous robotaxis while retaining the flexibility of free-floating sharing. The model preserves current individual trip patterns and excludes ride pooling, like illustrated in the agent-based fully autonomous model study in Austin24, thereby isolating the impact of partial autonomy.

Most fleet-sizing research for similar services is still grounded in agent-based simulations fed by synthetic demand: a recent review of 98 papers confirms that virtually all assume fully driverless vehicles and rely on generated trips or agent-based model rather than observations25. Only isolated efforts use empirical data, and even these are limited, like a Brooklyn pilot with 250 daily users rescaled ten-fold to create additional requests26, or a 3 km-wide last-mile study in Shenzhen focused mainly on charging policies27.

In contrast, the present work leverages a large-scale, real telematics dataset: 28,369 privately owned cars equipped with Unipol Group black-box devices produced 486,480 trips over a representative week in Milan. These data enable, for the first time, a data-driven simulation of a valet-style AMoD fleet under authentic spatio-temporal demand.

A purpose-built simulator, combining greedy nearest-vehicle assignment, battery-aware charging, and overnight proportional rebalancing, optimises fleet operations for this intermediate-autonomy set-up, which has so far been absent from the literature. Under stringent service constraints (waiting time \(\le\) 20 min; unmet requests \(\le\) 2%), only 2,300 valet AVs are needed, yielding a 12:1 reduction relative to the current private fleet. Crucially, the same vehicles reach an average utilisation of 31% of the day.

Under identical demand and service targets, a benchmark simulation of a conventional free-floating car-sharing system needs 7,750 vehicles, achieves only a 4:1 reduction, and attains a much lower utilisation of 7%. Remote-supervision resources are excluded from both scenarios, so the comparison reflects fleet performance alone.

Overall, the findings show that valet AMoD can shrink fleet size, quintuple utilisation, and curb emissions28, reducing battery and curb-space waste, well before full robotaxi deployment becomes feasible, thus providing a pragmatic bridge from private ownership to fully autonomous urban mobility.

Results

To demonstrate the feasibility of an urban AMoD service grounded in comprehensive real-world spatio-temporal data, we draw on a remarkably informative dataset provided through a research collaboration with UnipolTech, the telematics division of Unipol Group. This dataset covers approximately 120 million trips across Italy in 2022, recorded from around 100,000 vehicles registered in Milan, with each trip monitored by black-box devices equipped with GNSS and IMU (more information can be found in the Methods Section and in29). Such extensive private mobility information is rarely available. In contrast, many other studies rely on smaller-scale, agent-modeled, or outdated datasets that may not reflect current demand patterns30,31,32,33,34,35,36. By leveraging this robust dataset, our study presents a realistic simulation of everyday travel behavior, yielding core performance metrics that guide the determination of the optimal fleet size. We begin by outlining the key operational assumptions, the spatial and temporal characteristics of the observed private-car trips, and the simulation-based optimization methodology, ensuring that our findings better capture authentic mobility dynamics than those based on simplified or synthetic data sources.

Formulation of a quality of service measure

At the heart of the debate on AVs lies user acceptance, which reflects individuals’ willingness to adopt and trust this emerging technology37,38. Acceptance plays a pivotal role in how users perceive differences between an AV-based service and a traditional free-floating car-sharing model. For example, walking to a vehicle in a conventional service might occupy a similar amount of time as waiting for an AV, yet these experiences can be felt quite differently, owing to factors such as trust in autonomous systems, convenience, and overall psychological comfort.

To capture these nuances, we developed a Quality of Service (QoS) metric that translates the subjective perception of an AMoD valet-type service into a measurable parameter. More specifically, we focus on how long users are willing to wait for an autonomous vehicle before their comfort, and ultimately their acceptance, begins to decline. As illustrated in Fig. 2, the QoS score ranges from 1 (maximum comfort, corresponding to zero waiting time) to 0 (minimum comfort, corresponding to a 20-minute wait), beyond which a user’s request is deemed unsatisfied. This curve is derived from a user survey in which participants were first asked to rate their perceived comfort based on waiting times in a valet-style AV service (detailed in the Methods section). By grounding our analysis in both user acceptance factors and practical waiting time thresholds, we can more accurately gauge the feasibility and user appeal of an AMoD valet service.

Fig. 2
figure 2

Normalized Comfort curve enabling the definition of QoS as a function of waiting time.

Full size image

The QoS values are assembled into five distinct intervals of QoS, here listed in decreasing service quality and performance:

  • “Very Good” QoS: comfort value \(\in [1, 0.8]\)

  • “Good” QoS: comfort value \(\in (0.8, 0.6]\)

  • “Normal” QoS: comfort value \(\in (0.6, 0.4]\)

  • “Bad” QoS: comfort value \(\in (0.4, 0.2]\)

  • “Very Bad” QoS: comfort value \(\in (0.2, 0]\)

Aligning with the survey findings and the comparison with standard car sharing, it is worth noting that the worst service level, “Very Bad” QoS, cannot be reached. In all cases, measured comfort values remain above 0.2, indicating that even at a 20-minute wait, users’ perceived comfort does not degrade to an unfeasible level.

Milan streets graph

To represent the streets of Milan, the OpenStreetMap library is utilized, resulting in the connected network in Fig. 3,

Fig. 3
figure 3

Undirected and fully connected graph of all driveways characterizing the Milan urban space. The ”blue” highlighted dotted circle represents the chosen perimeter for the operational area of the urban AMoD service and has a radius of 14 km.

Full size image

The graph includes all real roads accessible by car within a 14 km radius to match a realistic circular service area, centered in the Duomo of Milan. The edges (roads) are supposed to be all bidirectional, to avoid complications and excessive computational burden arising from the use of a graph that is not strongly connected, which could lead to AVs becoming trapped in certain districts. This undirected graph covering all urban roads has the characteristic of containing a path from each vertex to every other vertex, featuring 60220 edges, 41343 nodes and covering an area of approximately 800 km\(^2\).

Car sharing simulator

Since the primary objective of the research is to determine the minimum size of urban autonomous valet-type on-demand fleet capable of adequately meeting the travel demand currently represented by the dataset of real trips made with private cars in the chosen urban context, this does not require the development of a model but rather the construction of a simulator that takes into account real spatial and temporal trips’ data as well as the multiple operational constraints of the autonomous fleet.

Therefore, the core contribution of this research is the development from scratch of a custom, sophisticated, parametric and flexible simulator capable of translating real private car trip demand into the flow of autonomous valet type cars, in order to meet demand according to constraints imposed by the potential operator. The goal is to achieve demand satisfaction with limited waiting times while simultaneously ensuring AVs performance in terms of charging and positioning.

The developed simulator, entirely implemented in Python, employs particularly efficient data structures and algorithms to minimize the computational time required for simulations. This easily allows for modifying input parameters, running new simulations, and therefore perform the necessary sensitivity analyses on key input parameters.

The simulator also includes the capability to monitor the State of Charge (SOC) of the electric AVs’ batteries and to manage charging over time at available and planned stations when needed. Additionally, the simulations incorporate a nighttime fleet rebalancing mechanism to increase the availability of AVs in areas where demand is consistently higher in the following morning peak time. Below, a more detailed description of both mechanisms is provided.

AVs recharging

As a first proxy for a reasonable recharging stations positioning, 12 hubs are simulated and are evenly distributed along a 7 km circumference centered in the Duomo of Milan. This is to say that the charging stations are placed approximately halfway across the radius of the AMoD service deployment area. Each hub is equipped with 22 kW charging stations (in this study unlimited in number per hub), reflecting the most common urban charging infrastructure in Italy. The AVs are assumed to have 46 kWh batteries, providing an autonomy range of 350 km, with a recharging time of 1.5 hours to recharge an equivalent range of 250 km using the 22 kW stations. Recharging time scales proportionally: for instance, an AV that has driven 125 km would require 45 minutes of charging. AVs remain at the hub until fully recharged. Recharging of the fleet self-driving vehicles is autonomously managed by the operation system, employing two distinct but simultaneously active logics:

  • On-demand logic: a continuous process active throughout the entire day. An AV is sent to the nearest charging hub as soon as it exceeds 250 km of travel.

  • Overnight logic: A single daily event triggered at 1:00 AM, directing all AVs that have traveled at least 100 km to the nearest hub for recharging.

All routes to the recharging hubs are performed by cars in autonomous driving mode, eliminating the need for human personnel. While our approach employs straightforward policies, such as those proposed in39, more advanced strategies could be implemented, as explored in studies like33,40, and34.

AVs rebalancing

In a car-sharing system, “rebalancing” refers to the process of repositioning vehicles within the service area to better match supply with demand. Since users pick up and drop off vehicles in different locations, imbalances can occur, leading to vehicle shortages in high-demand areas and excess supply in low-demand areas. In AMoD systems, rebalancing is crucial to maintain service efficiency and reduce waiting times. Here, the easiest rationale of static rebalancing is adopted and performed only during low-demand periods, where vehicles are relocated based on historical demand patterns.

The automatic rebalancing mechanism improves vehicle distribution and reduces user waiting times during peak morning demand, but is likewise introduced to mitigate AVs clustering at charging hubs during the night. The rebalancing logic activates at 4:00 AM and relocates all fully recharged AVs from the recharging hubs to morning peak higher-demand locations.

High-demand areas are identified using historical trip data from the UnipolTech dataset, which provides information on peak trip origins for each morning. This data-driven approach closely aligns rebalancing with actual users’ demand patterns, significantly enhancing its effectiveness. Vehicles reposition themselves, using autonomous driving technology, to their designated locations without requiring human intervention. While our approach uses historical trip patterns for simplicity and efficiency, alternative and more complex, dynamic and real-time rebalancing strategies are available, as discussed in36.

Simulator-based fleet minimization problem

The simulator presented here addresses the minimum fleet size problem for an AMoD valet-type service, a topic explored in a purely modeling context (i.e., without real demand data) in previous studies 31,32,41. The objective is to determine the smallest number of AVs needed to serve a given demand while maintaining a very high Quality of Service (QoS) and keeping the probability of “no service” (\(P_{ns}\)) below a specified threshold. In this context, a “no service” event arises when no AV is available within a 20 minutes waiting time.

Formally, we define the following optimization problem:

$$\begin{aligned} \begin{aligned} \min \;&N_{\text {cars}} \text { subject to} \;&\begin{aligned}&QoS_{\text {vg}}(N_{\text {cars}}) \;\;\ge 90\%\\&P_{ns}(N_{\text {cars}}) \;\;\le 2\%\\ \end{aligned} \end{aligned} \end{aligned}$$

where:

  • \(N_{\text {cars}}\) is the fleet size to be minimized,

  • \(QoS_{\text {vg}}\) is the percentage of trips served with a very good QoS level,

  • \(P_{ns}\) is the fraction of requests that cannot be fulfilled (due to unavailability or excessive waiting time).

To solve this problem, we iteratively increase the number of AVs until the constraints on \(QoS_{\text {vg}}\) and \(P_{ns}\) are both satisfied. In each iteration, the simulator processes real trips one by one, according to their actual start position and timestamp. For each trip, the system checks whether an AV is available within the maximum waiting time of 20 minutes; if it is, the request is fulfilled and the user’s QoS is recorded, otherwise the trip is labeled as “no service.” Once an AV strats a trip, it is marked “busy” until the passenger has exited. This process continues until all trips in the dataset have been evaluated.

Figure 4 summarizes the overall workflow and architecture of the simulator.

Fig. 4
figure 4

Schematic representation of the iterative optimization. In each run, the simulator assesses whether the current fleet size meets the \(QoS_{\text {vg}}\) and \(P_{ns}\) constraints; if not, the fleet is incremented and the process repeats.

Full size image

As illustrated in Fig. 4, the simulator operates based on the following fixed input elements, which define the initial conditions and remain unchanged throughout the simulation. These inputs can be adjusted to reflect different urban contexts:

  • Urban mobility graph: from this graph a street network matrix of minimum distances between every pair of nodes is precomputed (see Methods Section). This removes the need for repeated shortest path calculations.

  • Real travel demand: A dataset specifying each trip’s origin, destination, and start/end times, representing actual mobility demand.

  • Initial fleet size: \((N_{\text {cars}})\). The starting number of AVs in the fleet. For this analysis, the initial fleet size is set at 1,800 vehicles.

  • Constraint thresholds: Numerical targets for \(QoS_{\text {vg}}\) (at least 90%) and \(P_{ns}\) (no more than 2%).

  • Incremental fleet step: The amount by which the fleet size is increased if constraints are not met in a given iteration. In this setup, the increment is set at 25 vehicles.

  • QoS intervals: The labeled intervals (e.g., “Very Good,” “Good,” etc.) defined by the comfort function.

  • Maximum iterations: A safeguard to prevent excessive runtime if constraints cannot be satisfied. In this scenario, the cap is set at 50.

  • AV speed: Fixed at 16 km/h in autonomous mode (slightly lower than the dataset’s 20 km/h average for safety considerations). When the AV is driven by the client, the velocity is the same of the original real trip.

  • Maximum waiting time: Set to 20 minutes for all trips.

  • Recharging stations: The locations of recharging hubs.

  • Recharging policies (Day and Overnight): Trigger points directing AVs to the nearest hub once a distance threshold is exceeded.

  • Rebalancing logic: A mechanism repositioning AVs overnight to high-demand areas for the following day.

After each run, if all constraints are satisfied, the optimizer terminates and provides the following outputs:

  • Trip fulfillment records: A list of trips successfully served, including each user’s waiting time.

  • Vehicle availability timeline: A record of how many AVs are busy or idle at each time step.

  • No service events: Details of any trips not served within the waiting threshold.

  • QoS dictionary: The distribution of requests across different QoS intervals.

  • Daily distance logs: A dataframe indicating, for each AV, how many kilometers it travels on each day of the week.

  • Per-AV statistics: A summary of metrics such as total distance, time in autonomous mode (“overhead”), time idle, and the number of trips fulfilled.

By collating these outputs across iterative runs, the simulator identifies the optimal fleet size for the AMoD valet-type service while maintaining user satisfaction targets and minimizing “no service” events.

Simulation outcomes and findings

The simulator-based optimization determined that a fleet of 2,300 AVs is sufficient to serve the observed travel demand, representing a 12-fold reduction compared to the 28,369 private vehicles in the original dataset. Despite this substantial downsizing, the AMoD valet system maintains a very good Quality of Service (QoS) in 90.08% of cases, with only 0.76% of requests unmet, which is within an acceptable margin. Additionally, the average user waiting time is just 2 minutes and 35 seconds, demonstrating that the system can provide timely mobility solutions. These findings highlight the efficiency and feasibility of a data-driven AMoD deployment in an urban environment.

Figure 5 illustrates the availability of AVs throughout the day, using Tuesday as a representative weekday.Two demand peaks are visible between 6:30–8:30 AM and 4:30–6:30 PM, corresponding to morning and evening commute periods. Additionally, two operational peaks occur at 1:00 AM and 4:00 AM, reflecting the overnight recharging and rebalancing mechanisms. During these times, vehicles are temporarily unavailable, but since user demand is low, service quality remains unaffected. These mechanisms ensure that the fleet is fully charged and optimally positioned for the following day.

Due to the high utilization of AVs throughout the day, each vehicle covers a significantly greater daily distance than private cars. Figure 6 shows the average daily mileage per AV, highlighting the efficient resource utilization.

Across the entire simulation, the maximum distance driven by any vehicle is 280 km, well below the assumed electric range of 350 km; this confirms that the automated recharging policy keeps the fleet operational without ever breaching battery limits.

Fig. 5
figure 5

Hourly availability of AVs on a typical weekday, illustrating demand peaks and operational recharging and rebalancing logics effects.

Full size image
Fig. 6
figure 6

Average daily distance traveled by AVs.

Full size image
Fig. 7
figure 7

Yearly mileage distribution of the AVs in the simulated AMoD fleet.

Full size image

Making a rough projection, over a one year period, the average mileage per AV would be around 53,000 km, compared to just 12,000 km of private vehicles in Europe 2 on average. This fivefold increase reflects the efficiency of fleet-based AV services in reducing total vehicle count while maintaining mobility needs. The distribution of yearly mileage per AV is shown in Fig. 7.

The average utilization time for the AMoD fleet is 30.94%, of which 23.24% spent in autonomous mode. In contrast, private vehicles remain parked for 95% of the time 42, highlighting the potential of AV-based services to improve vehicle efficiency.

Interestingly, the percentage of total kilometers traveled in autonomous mode relative to the overall kilometers is only 18.75%. This reinforces the viability of the valet style AMoD service as a transitional model toward full autonomy.

To test the system’s resilience, we fictionally simulated a high-demand scenario, such as a major trade fair or mass event, by condensing all weekly trips into a single day. Despite the increased load, the fleet reduction ratio remains consistent at 1:12, confirming the scalability and robustness of the AMoD valet system.

The observed utilization rates and fleet reduction factors align with a previous significant study on shared autonomous mobility43, further validating the feasibility of large-scale AMoD deployment.

What would be the fleet size for a traditional MoD service with free-floating cars to meet the same mobility demand of the AMoD one?

Free-floating car-sharing services are an established component of urban mobility ecosystems and operate in many large cities, including Milan, where multiple providers coexist. These services enable users to locate available vehicles via a mobile application, walk to the nearest car, drive to their destination, and park in designated areas.

While car-sharing services provide flexibility and an alternative to private vehicle ownership, their effectiveness depends on maintaining a sufficiently large and well-distributed fleet to ensure reliable vehicle availability. However, several challenges limit their scalability and widespread adoption, as highlighted by the research in44:

  • Limited vehicle availability: Users may struggle to find an available car when needed, introducing uncertainty and reducing service reliability.

  • Service complexity: The process of locating, reserving, and accessing vehicles can be perceived as cumbersome, discouraging potential users.

  • Psychological barriers: Concerns related to shared vehicle cleanliness, security, and personal safety may deter individuals from adopting car-sharing services.

  • Low public awareness: Many potential users remain unfamiliar with car-sharing models, leading to limited adoption and engagement.

  • Sensitivity to waiting time: The probability of using car-sharing services decreases as access time increases, making immediate availability a key factor in user satisfaction.

Addressing these limitations would require providers to significantly expand fleet size, optimize vehicle distribution, and improve user experience through infrastructure investments and operational adjustments. However, the costs associated with overcoming these barriers, such as increasing vehicle density, deploying advanced fleet management systems, and ensuring high service reliability, would be financially unfeasible or economically unviable in most urban environments.

Given these operational and economic challenges, we compare, under identical real-world travel demand and service quality conditions, the minimum fleet size required for a valet-type Autonomous Mobility-on-Demand (AMoD) service (described in the previous section) against a traditional free-floating Mobility-on-Demand (MoD) system. A detailed treatment of behavioural and psycho-social barriers is beyond the scope of the present study.

To properly simulate a free-floating car-sharing system, it is necessary to model both the walking and driving segments of each trip. This requires two distinct network representations: the driving graph, which includes all roads accessible by vehicles, and the walking graph, which represents pedestrian pathways. The walking graph, depicted in Fig. 8, covers all walkable pathways within the 14 km circular service area centered in Milan.

Fig. 8
figure 8

Walk graph representing pedestrian pathways within the Milan service area.

Full size image

Unlike the driving graph, the walking graph is intrinsically undirected since pedestrian paths can be traversed in both directions without restriction. The comparison between the two networks highlights clear structural differences: pedestrian areas and parks, which contain no edges in the driving graph, are well-connected in the walking graph, allowing for a more detailed representation of possible user movements. The driving graph consists of 41,343 nodes and 60,220 edges, while the walking graph is significantly denser, with 179,251 nodes and 263,885 edges, reflecting the finer granularity of pedestrian pathways.

In the simulation, it is essential to ensure that every shared vehicle is parked at a location accessible by foot. To achieve this, only nodes that are common to both the walking and driving graphs are retained, ensuring consistency between pedestrian access and vehicle availability. A filtered list of common nodes (approximately 39,000) is generated, preserving all edges from both graphs. This allows users to freely navigate walkable paths while ensuring that trips originate and terminate only at these valid locations. This approach prevents errors caused by vehicles being placed in inaccessible areas and eliminates GPS inaccuracies or inconsistencies that may arise from incomplete datasets.

Trips that start or end at nodes outside this valid set, such as highways or areas without pedestrian access, are removed from the dataset to ensure that all simulated journeys reflect feasible real-world conditions. This structure guarantees that users can always reach a shared vehicle on foot before beginning their driving segment, maintaining the integrity of the simulation.

Following the integration of both walking and driving networks in the simulation, we examine how different access methods impact user experience. While the previous analysis focused on the effect of waiting times in an autonomous valet system, this evaluation incorporates the role of walking time in free-floating car-sharing scenarios.

To quantify user perception, the survey previously used to assess the comfort metric of the AMoD service included a second section, where participants were asked to evaluate their comfort when walking to a free-floating car-sharing vehicle (see Methods section). This structured approach enables a direct comparison of how different access modes influence the perceived quality of service. The simulator uses the same real-world trip dataset but applies distinct Quality of Service (QoS) curves based on the time required to reach a vehicle by walking, as illustrated in Fig. 9.

To accurately model free-floating car-sharing operations, the simulator was modified to incorporate walking-based vehicle access. When a trip request is generated, the system identifies the nearest available vehicle using the pedestrian graph, and the user proceeds toward it. For simplicity, a constant walking speed of 4 km/h is assumed. The trip is then divided into two sequential phases: (1) a walking segment on the pedestrian graph, where distances and travel times are computed based on the user’s movement toward the vehicle, and (2) a driving segment on the road graph, where the vehicle follows the original trip characteristics observed in the dataset.

Upon reaching the final destination, additional fixed times are introduced to reflect real-world usage patterns. A 60 second delay accounts for parking the shared vehicle, while an additional 90 second transition period represents the user’s final movement to their intended location. This structured approach ensures that walking time is explicitly considered in the simulation, providing a more accurate representation of user experience.

Fig. 9
figure 9

Normalized Comfort curves enabling the definition of QoS as a function of waiting or walking time.

Full size image

The simulation results, summarized in Table 1, demonstrate the significant impact of walking time on both service perception and operational efficiency.

Table 1 Comparison of key performance indicators (KPIs) between free-floating Mobility-on-Demand (MoD) and Autonomous Mobility-on-Demand (AMoD) valet services.
Full size table

The simulation results demonstrate the significant impact of walking time on both service perception and operational efficiency. Free-floating car-sharing requires a substantially larger fleet to maintain service reliability, whereas valet-based AMoD achieves comparable service quality with significantly fewer vehicles. The autonomous valet-type service operates with a much smaller fleet, replacing up to 12 private cars per shared autonomous vehicle, while traditional free-floating sharing achieves a lower replacement ratio of only four private cars per shared vehicle. This highlights, on a real data-driven basis, the improved fleet utilization enabled by the AMoD model, as visually depicted in Fig. 10.

Fig. 10
figure 10

Ratio of fleet sizes starting from private cars, the free-floating traditional car sharing service, and the autonomous valet type service.

Full size image

In terms of operational efficiency, the utilization percentage in the AMoD scenario is about four times higher than in the free-floating car-sharing model. A comparable utilisation boost was also found in Munich for autonomous electric taxis replacing free-floating cars39. Each autonomous vehicle covers a significantly higher daily distance, demonstrating more intensive fleet usage. However, the AMoD model also introduces overhead kilometers, accounting for 18.75% of total travel, as vehicles must reposition autonomously. This factor is absent in traditional sharing, where cars remain stationary until manually accessed by users. Service perception is strongly influenced by the access method. The added inconvenience of walking to a shared vehicle in free-floating systems leads to a steeper decline in quality of service compared to waiting for an autonomous valet vehicle. While both systems satisfy the imposed QoS constraints, the results emphasize how walking time negatively affects user experience, making autonomous valet solutions a more attractive alternative.

Sensitivity analysis on QoS constraints

To further examine the impact of service quality expectations on fleet sizing, a sensitivity analysis was conducted by iteratively solving the fleet minimization problem while progressively tightening the minimum QoS constraint. The objective was to observe how increasingly stringent user expectations influence the required number of vehicles in both autonomous valet and free-floating car sharing models.

The results, visualized in Fig. 11, reveal a stark contrast in system scalability. As \(QoS_{\text {vg}}\) tends to 100%, the AMoD fleet size experiences only a marginal increase, demonstrating its ability to maintain high service quality with a relatively stable fleet size. Conversely, the traditional free-floating car-sharing model exhibits exponential fleet growth, indicating that an exceptionally large number of vehicles would be required to meet extreme QoS expectations.

Fig. 11
figure 11

Impact of increasing \(QoS_{\text {vg}}\) constraint on fleet size in AMoD valet type and traditional MoD services.

Full size image

These findings highlight a key limitation of free-floating car-sharing: ensuring high service quality requires a disproportionately large fleet, making the system increasingly inefficient as user expectations rise. In contrast, the autonomous valet model exhibits greater scalability, providing consistent \(QoS_{\text {vg}}\) without excessive fleet expansion.

Discussion

Advancements in autonomous driving technology, driven by companies such as Waymo, Tesla, and Cruise, along with growing global research efforts, are shaping the future of mobility. Simultaneously, increasing environmental awareness and the increasing need for urban free space are accelerating the transition toward shared mobility solutions. This study demonstrates the potential of an autonomous valet model as a hybrid approach that, on one side, enhances traditional free-floating car sharing increasing the vehicle replacement ratio from 1:4 to 1:12 within the same operational framework, and on the other side has much more immediate implementation possibilities as it requires less technological effort and supervision.

By integrating autonomy with shared mobility, this model mitigates key limitations of existing car sharing systems while reducing the structural and operational complexities of fully autonomous services like robotaxis. It enhances service reliability by improving vehicle availability, reducing user walking distances, and eliminating parking inefficiencies. Unlike conventional car sharing, which requires large fleets to ensure service quality, the AMoD system achieves similar performance with significantly fewer vehicles. This translates into lower operational costs, reduced congestion, and decreased demand for public parking space.

A key advantage of the autonomous valet model is its ability to dynamically reposition vehicles based on demand, leading to higher fleet utilization. This not only improves cost amortization but also maximizes the benefits of high-capacity electric batteries, reinforcing the environmental advantages of shared autonomous fleets. Furthermore, by maintaining a service experience comparable to private car ownership, valet AMoD offers a viable alternative to individual vehicle ownership, promoting a shift toward more sustainable urban transportation.

In summary, valet based AMoD service presents a scalable and efficient mobility solution, optimizing fleet size, improving accessibility, and enhancing resource utilization. By leveraging automation and full electric powertrain, these system can significantly reduce urban vehicle density, free up public space, and lower emissions, reaffirming the role of autonomous driving in transforming transportation toward a more sustainable future.

Limitations

While the study provides evidence of the fleet-saving potential of valet-style AMoD, several simplifying assumptions bound the scope of our findings:

  1. 1.

    Fixed, inelastic travel demand. The simulator replays one representative week of observed private-car trips collected via Unipol telematics. Robustness tests are made on another weeks and a synthetic “10×” stress case compressing ten weeks of demand into one-yielded virtually identical fleet-reduction ratios, yet demand remains exogenously fixed.

    Future work will endogenise demand by coupling the simulator with a behavioural model in which price, reliability, and waiting time jointly influence trip generation and mode choice.

  2. 2.

    User Acceptance Assumption: This study does not explicitly address user acceptance of AV-based car-sharing services. Instead, it assumes that users are willing to adopt both autonomous and traditional car-sharing services in place of private car ownership. Future research should explore the factors influencing user adoption and willingness to transition to shared mobility solutions.

  3. 3.

    Survey sample and preference bias: Comfort curves are based on a stated-preference survey with 46 expert respondents, a size and composition that may not reflect the broader population. A larger, bias-controlled survey, in collaboration with external research groups, is already being planned to refine these behavioural inputs.

  4. 4.

    Vehicle-level data only. The dataset does not contain party size, trip purpose, or household attributes. Trips are therefore treated as single-party, point-to-point movements with no ride-sharing or trip-chaining. A person-based demand model would allow us to study shared rides and multi-stop tours.

  5. 5.

    GNSS and matching accuracy. Raw GPS fixes (typical error 5–10 m) are snapped to the nearest node of the drive graph. This absorbs most location noise but may shift origins or destinations lying inside private courtyards or car parks to the closest public node.

  6. 6.

    Infrastructure simplifications. The core simulation uses twelve ideal, evenly spaced 22 kW charging hubs. A sensitivity test relocating the same twelve hubs to existing interchange car parks in Milan slightly changes the optimal fleet size and QoS metrics, indicating that the main results are robust to realistic hub placement. Kerb-space and detailed parking constraints are still abstracted and will be examined in future work.

  7. 7.

    Fleet reliability and special-purpose vehicles. Vehicles are assumed fault-free and homogeneous; no child-seat or accessibility requirements are modelled. Including downtime and heterogeneous vehicle types would increase the required fleet.

  8. 8.

    Centralised single operator. A monopolistic dispatcher maximises system-wide performance. Splitting the market among multiple operators, each optimising its own sub-fleet, would likely reduce efficiency; this will be investigated in subsequent studies.

Methods

Trip data collection system, preprocessing and final dataset

The GNSS receivers employed in this study are embedded within a specialized case referred to as telematics “black box”, firmly installed on the car’s battery. The about 5 Mio boxes circulating in Italy are also equipped with an Inertial Measurement Unit (IMU), enhancing the precision and reliability of gathered data. The IMU, working at a max frequency of 200Hz, supplements GNSS-derived positioning information, usually sampled at 10Hz, by providing details regarding device orientation and acceleration. The black boxes predominantly utilize modules such as Quectel Mc60, u-blox modules, or ST Teseo variants of different brands. Data acquisition is made through the reception of NMEA (National Marine Electronics Association) messages, specifically in the $GNRMC format. These messages, sent approximately every 2 kilometers or 5 minutes, contain essential data including UTC time, latitude, longitude, speed, heading, and ground speed. The 2-kilometer or 5 minutes interval ensures that data transmission from sensors does not excessively overload the centralized server memory while maintaining adequate data collection aligned with the study’s objectives. The black box is continuously powered, drawing energy directly from the vehicle’s battery or, in some instances, from an onboard battery source. This uninterrupted power supply ensures seamless data collection throughout the whole observation period. The dataset derives from the black box tracking in position and time of approximately 100,000 private vehicles registered in Milan, completing approximately 120 million trips across Italy between January and December 2022. The data collected are mainly used for insurance related purposes, including evaluation of driver behavior, accident reconstruction in case of crashes, vehicle tracking in the event of theft, and more. Notably, the dataset includes information on the average speed of trips for each vehicle, duration, starting point and ending point and distance traveled.

To ensure the reliability of the dataset and the feasibility of the analysis, a structured data cleaning process is performed to exclude trips affected by GNSS inaccuracies, outliers or errors, or unrealistic conditions. The preprocessing criteria are as follows:

  1. 1.

    Trips with a total distance shorter than 500 meters are excluded.

  2. 2.

    Trips with a total duration of less than 5 minutes or longer than 12 hours are removed.

  3. 3.

    Trips with an average speed lower than 5 km/h or faster than 150 km/h are considered unfeasible and are eliminated.

Furthermore, vehicles with more than 70% of their trips eliminated during the preprocessing phase are also excluded from the research.

Following data cleaning, we define the service area of the Autonomous Valet Service as a circular region centered at Milan’s Duomo, with a radius of 14 km, so approximating the Milan metropolitan area. To focus the research on urban mobility demand, we further filter the dataset to retain only vehicles for which at least 70% of trips originate and terminate within this defined service area.

After applying these selection criteria, the final dataset comprises 3.7 million trips from approximately 30,000 vehicles, ensuring a sufficiently large sample size for statistically significant analyses. For computational feasibility, a subset of the dataset spanning two weeks (February 28–March 14, 2022) is selected. Trip data in these two weeks serve distinct purposes in the simulation workflow:

  • Week 1 (February 28–March 7, 2022): trip data used to initialize the demand-based rebalancing mechanism. During this phase, vehicle trip start points recorded between 6:00 AM and 8:30 PM are utilized to predict demand patterns for the following week in the same time slots. The rebalancing algorithm moves cars based on these historical trip data to optimize their positioning for the next day’s morning peak hour requests. This assumption is grounded in the proven fact that normal weeks’ trip patterns, for a sufficiently large population, tend to be repetitive.

  • Week 2 (March 7–March 14, 2022): trip data effectively employed as mobility demand in the simulations and hence as groundtruth for the actual Autonomous Valet Service design. This dataset includes 486,480 trips from 28,369 unique cars, providing a high-resolution representation of real-world urban mobility demand.

This data-driven approach avoids the need for predictive demand models, which may introduce inaccuracies and degrade service quality. Instead, the historical week-by-week structure ensures realistic and repeatable mobility patterns in the simulation.

For plausibility, we compare our sample with official traffic counts. Milan records about 400,000 intra-city private-car trips per weekday (\(\approx 0.30\, \text {car trips} \cdot \text {capita}^{-1} \cdot \text {day}^{-1}\)). The 486,480 trips retained for Week 2 therefore represent roughly \(17\,\%\) of all private-car movements during the same seven-day period, even though the 28,369 black-box vehicles account for only about \(6\,\%\) of the city’s private fleet (\(\approx 700{,}000\) cars). This coverage ratio confirms that the dataset captures a substantial and realistic slice of daily car demand.

Request matching and speed setting

Each trip request is processed in chronological order. Because the dataset contains vehicle-level trajectories only, no information on party size, trip purpose, or ride-sharing is available; every request is therefore treated as a single, point-to-point trip. A request is matched to the nearest idle AV that can reach the pick-up node within the 20-min waiting threshold, keeping the dispatch logic lightweight and reproducible.

The simulator assumes an average empty-running speed of 16 km/h. Three considerations motivate this value:

  1. (a)

    The Unipol telematics dataset reports an average urban speed of approximately 20 km/h for private cars in Milan29.

  2. (b)

    A 30 km/h cap aligns with the policy increasingly adopted by European municipalities to enhance road safety45.

  3. (c)

    In a 500 km on-road experiment we conducted, for another research purpose, with a conventional car limited to 30 km/h, the observed average speed in Milan’s urban traffic was 16 km/h, confirming that congestion and signal delays, rather than the speed cap itself, determine typical cruising speeds.

Night-time rebalancing logic

At 04:00 am all idle, fully-charged AVs are repositioned ahead of the morning peak. Historical demand is pre-aggregated into five 30-minute slots between 06:00 am and 08:30 am. For each slot a CSV file lists network nodes and their trip counts, sorted in descending order. The algorithm proceeds greedily yet proportionally:

  1. (i)

    For the first slot (06:00–06:30 am) vehicles are assigned sequentially to nodes until the idle fleet is exhausted.

  2. (ii)

    Any remaining idle AV is distributed in the same way for the subsequent slots (06:30–07:00 am, 07:00–07:30 am, 07:30–08:00 am, 08:00–08:30 am).

  3. (iii)

    If vehicles run out before lower-ranked nodes are filled, those nodes remain uncovered; conversely, surplus vehicles spill over to later slots.

This ensures that the busiest early-morning clusters receive coverage first, without excessive vehicle clustering, and guarantees baseline availability for the very first requests of the day.

Urban mobility graphs

To simulate AVs movement within the service area, graphs representing Milan’s road network are needed and built using OpenStreetMap (OSM). These graphs enable the application of pathfinding algorithms, such as Dijkstra’s algorithm46, to efficiently compute the shortest paths between origins and destinations. The Python library NetworkX47 is used for graph construction and processing. The simulations rely on two graphs:

  • The Drive Graph, representing the network of driveways, consisting of 41,343 nodes and 60,220 edges.

  • The Walk Graph, representing the pedestrian pathways, is much denser, with 179,251 nodes and 263,885 edges.

Both graphs are centered at Milan’s Duomo and span a 14 km radius urban area. All raw GNSS coordinates are first snapped to the nearest node of the drive graph, so the typical 5–10 m sensor error is absorbed by the graph topology before any further distance calculation.

For the AMoD valet service, only the Drive graph is needed. In contrast, traditional free floating car sharing requires both the Drive and Walk graphs. To ensure vehicles are parked in accessible locations while preserving pedestrian mobility, only the nodes common to both graphs are retained for vehicle placement. This approach prevents inconsistencies such as vehicles being placed on highways or in pedestrian only zones, while still allowing unrestricted pedestrian movement by maintaining all edges in the Walk graph.

Running Dijkstra’s algorithm dynamically during simulations would be computationally prohibitive due to its complexity of \(\mathcal {O}(M + N \log N)\), where \(N\) is the number of nodes and \(M\) is the number of edges. To optimize performance, two precomputed street network distance matrices are generated: one containing minimum driving distances and another for walking distances. These matrices, stored as NumPy arrays, allow constant time reading of the precomputed distances between nodes, significantly improving simulation efficiency.

Quality of service definition through a survey

To quantify user perceived service quality, a survey was conducted to assess discomfort levels associated with accessing cars in the two shared mobility models, AMoD and MoD. The survey was distributed among collegues at Politecnico di Milano, ensuring reliable responses from mobility experts.

Participants were asked to evaluate their discomfort on a scale from 0 (no discomfort) to 10 (maximum discomfort) for different waiting times (from 2 minutes to 30 minutes) in the autonomous valet scenario and walking times in the traditional car-sharing model. The 46 collected responses were used to construct Quality of Service (QoS) curves, mapping waiting/walking time to comfort levels.

The survey results confirm that user discomfort increases with longer access times, with walking perceived as significantly more inconvenient than waiting. For waiting/walking times exceeding 20 minutes, responses indicated a level of discomfort that would likely result in opting for alternative transportation modes. As a result, any service request exceeding this threshold was classified as “no service” in simulations.

The perceived service quality comfort values have been normalized with respect to the maximum and merged into into five categories: “very good,” “good,” “normal,” “bad,” and “very bad”, as illustrated in Fig. 9 and embedded into the simulator, to effectively account for the user’s perception.