Electric Vehicle Route Optimization: An End-to-End Learning Approach with Multi-Objective Planning

Abstract

Traditional routing algorithms optimizing for distance or travel time are inadequate for electric vehicles (EVs), which require energy-aware planning considering battery constraints and charging infrastructure. This work presents an energy-optimal routing system for EVs that integrates personalized consumption modeling with real-time environmental data. The system employs a Long Short-Term Memory (LSTM) neural network to predict State-of-Charge (SoC) consumption from real-world driving data, learning directly from spatiotemporal features including velocity, temperature, road inclination, and traveled distance. Unlike physics-based models requiring difficult-to-obtain parameters, this approach captures nonlinear dependencies and temporal patterns in energy consumption. The routing framework integrates static map data, dynamic traffic conditions, weather information, and charging station locations into a weighted graph representation. Edge costs reflect predicted SoC drops, while node penalties account for traffic congestion and charging opportunities. An enhanced A* algorithm finds optimal routes minimizing energy consumption. Experimental validation on a Nissan Leaf shows that the proposed end-to-end SoC estimator significantly outperforms traditional approaches. The model achieves an RMSE of 36.83 and an $R^2$ of 0.9374, corresponding to a 59.91% reduction in error compared to physics-based formulas. Real-world testing on various routes further confirms its accuracy, with a Mean Absolute Error in the total route SoC estimation of 2%, improving upon the 3.5% observed for commercial solutions.

1. Introduction

The increasing adoption of electric vehicles (EVs) worldwide is driven by the need for sustainable transportation solutions that reduce greenhouse gas emissions and dependence on fossil fuels [1]. However, the widespread implementation of EVs also introduces new challenges, especially concerning battery constraints and energy management [2,3]. Traditional route planning algorithms typically optimize for either the shortest distance or the fastest travel time [4]. These approaches, while effective for internal combustion engine vehicles, fall short for EVs due to their unique characteristics—limited driving range, battery degradation issues, and the influence of external factors such as terrain and climate conditions on energy consumption.

In the context of EVs, route optimization must account for multiple interdependent objectives. Beyond merely reaching the destination, the selected path should ideally minimize energy usage, preserve battery health, and manage travel time. Some recent studies have attempted to address multi-objective route optimization for EVs [5]. Some focus on charging station placement [6], while others introduce modified versions of classic graph algorithms like Dijkstra or A* to include energy parameters [7]. However, many of these approaches either simplify the vehicle energy model or neglect the trade-offs between energy use, battery stress, and travel time.

This work presents an energy-optimal routing system specifically designed for the unique characteristics and constraints of EVs. The framework integrates an end-to-end energy consumption model that accounts for both vehicle dynamics and individual driving style with a multi-objective route planner. The street network is represented as a graph, with edges weighted by a composite cost function that integrates traffic, charging stations, travel time, and the personalized energy model. A complete diagram of the proposed framework is shown in Figure 1.

Based on the presented planning framework, the main contributions of this work are as follows:

• Development of a vehicle model using real-world data. This model learns and captures the vehicle’s specific characteristics as well as the driver’s individual style as inferred from that data.
• A realistic routing system that considers the traffic conditions, charging points, travel time, and the personalized vehicle model.
• A comparison between a traditional physics-based model and the proposed learning-based model.
• Real-world validation of the proposed system, including a comparison against commercial solutions.

1.1. Related Works

The development of the proposed route planning system in this work requires knowledge from multiple domains. Specifically, it involves the modeling of EVs to accurately estimate energy consumption, a review of planning methods for optimal route computation with a particular focus on EVs, and an examination of works that integrate environmental information and commercial approaches.

1.1.1. Electric Vehicle Model

The main goal of the route planner is to find the optimal path based on energy consumption; therefore, the vehicle model is one of the most critical components. Traditionally, this model has been developed using a physical representation of the vehicle to calculate energy usage [8,9]. However, such approaches rely on specific parameters that are often difficult to obtain. These methods typically incorporate a key characteristic of EVs: their ability to regenerate energy during braking or when driving downhill [10]. Other approaches base route planning on range estimation models constructed using standard driving cycles, adapted from combustion engine vehicle data [11]. While these models yield more realistic estimations, they suffer from limitations in accurately adapting combustion-based models to EVs. A more refined approach involves using real-world data from EVs. In this case, a traditional vehicle model is employed to parametrize a regression model, which can predict energy consumption using easily accessible input parameters such as travel distance, travel time, and temperature [12]. In this work, we propose to enhance this approach by introducing an end-to-end learning-based method that can replicate the vehicle model directly from real-world data.

1.1.2. Route Planning for Electric Vehicles

Finding the shortest path between two nodes in a predefined graph is a well-established problem in the literature. Classical algorithms such as Dijkstra’s algorithm [13] compute the shortest path from a source node to all others by iteratively selecting the node with the lowest tentative distance. The A* algorithm [14] improves on Dijkstra by incorporating a heuristic to guide the search, which can significantly reduce the computation time in large graphs. Bellman-Ford [15], while less efficient, is able to handle graphs with negative edge weights. However, in the context of EVs, drivers often experience range anxiety—concern about whether the vehicle has enough charge to reach the destination, which can influence driving behavior toward more conservative styles [16]. As such, the goal of EV-specific route planning is not simply to find the shortest route but to determine an optimal route that balances energy consumption, driving comfort, and feasibility. In this direction, some works estimate the range of the vehicle while considering traffic conditions to identify efficient routes [17], while others improve the Dijkstra algorithm by incorporating charging station availability and real-time traffic data [18]. Although these methods address important constraints, they typically focus on a subset of the problem. The most comprehensive approach we have identified employs multi-objective optimization to simultaneously minimize energy consumption, travel time, and battery degradation [19]. Building on this foundation, our work replicates such a planner as a baseline and extends it by introducing a learning-based model that dynamically defines the cost function weights based on real-world data.

1.1.3. Commercial Route Planners for Electric Vehicles

Commercial navigation systems for EVs offer a wide range of functionalities, though each presents specific trade-offs. Google Maps provides real-time traffic information and charger availability, but its EV features are limited to specific platforms and lack fine-grained customization [20]. Waze supports charger discovery but does not integrate battery state or energy-aware planning [21]. A Better Routeplanner (ABRP) is highly detailed and EV-centric, supporting precise energy modeling and live vehicle data integration, but it requires separate navigation tools and a subscription for advanced features [22]. PlugShare excels at crowdsourced charger data and station reviews, yet it does not optimize routes or model energy use [23]. TomTom and HERE offer robust EV routing APIs with support for state-of-charge (SoC)-aware planning, multi-stop optimization, and real-time traffic, but they are proprietary and primarily designed for enterprise integration [24,25]. In contrast, open-source platforms such as GraphHopper and OpenRouteService offer transparency and flexibility, though they lack native EV-aware routing and rely on community or user-defined enhancements [26,27]. In this work, we build on the open-source GraphHopper engine to implement a personalized and energy-optimal EV routing system, extending its capabilities with a learned vehicle model, dynamic cost functions, and real-world data integration—features that are not jointly addressed in the reviewed platforms.

2. Electric Vehicle Model

Since consumption depends on vehicle dynamics, auxiliary loads, and environmental conditions, accurate estimation is crucial for route planning under battery and range constraints. In this section we discuss the two approaches evaluated in this work: (1) a physics-based model, and (2) our proposed neural network model for personalized consumption prediction.

2.1. Physics-Based Energy Model

The physics-based energy model follows the formulation in Perger et al. [19]. The total driving force $F_{\mathrm{drive}}$ acting on an EV is expressed as the sum of three components: rolling resistance $F_{\mathrm{roll}}$, aerodynamic drag $F_{\mathrm{air}}$, and gravitational (gradient) resistance $F_{\mathrm{grad}}$:

$$F_{\mathrm{drive}}=F_{\mathrm{roll}}+F_{\mathrm{air}}+F_{\mathrm{grad}}=mg{f}_{R}cos\left(\alpha \right)+{\displaystyle \frac{1}{2}}\rho c_{w}A{v}^2+mgsin\left(\alpha \right)$$

(1)

The instantaneous power required to overcome this total resistance is:

$$P_{\mathrm{drive}}\left(t\right)=F_{\mathrm{drive}}\left(t\right)·v\left(t\right)$$

(2)

and the total mechanical energy needed to drive over a time interval $[t_1,t_2]$ is obtained by integration:

$$E_{\mathrm{drive}}={\int }_{t_1}^{t_2}{P}_{\mathrm{drive}}\left(t\right)dt$$

(3)

In EVs, the battery is the sole source of energy for both driving and auxiliary systems. The total energy drawn from the battery E must account not only for $E_{\mathrm{drive}}$, but also for auxiliary consumers such as heating ($E_{\mathrm{hc}}$), cooling, lighting, and other accesories systems ($E_{\mathrm{acc}}$), each flowing through different components with distinct efficiency losses. The discharged energy is therefore given by:

$$E={\displaystyle \frac{1}{{\eta }_{\mathrm{dis}}}}\left({\displaystyle \frac{1}{{\eta }_d{\eta }_m{\eta }_{\mathrm{inv}}}}{E}_{\mathrm{drive}}+{\displaystyle \frac{1}{{\eta }_{\mathrm{acc}}}}{E}_{\mathrm{acc}}+{\displaystyle \frac{1}{{\eta }_{\mathrm{hc}}}}{E}_{\mathrm{hc}}\right)$$

(4)

When the vehicle is braking or driving downhill, the drivetrain can regenerate energy. In this case, the motor acts as a generator, and $P_{\mathrm{drive}}\left(t\right)<0$. The recovered energy, after conversion losses, is returned to the battery:

$$E_{\mathrm{out}}=-{\eta }_d{\eta }_g{\eta }_{\mathrm{inv}}{E}_{\mathrm{regen}}+{\displaystyle \frac{1}{{\eta }_{\mathrm{acc}}}}{E}_{\mathrm{acc}}+{\displaystyle \frac{1}{{\eta }_{\mathrm{hc}}}}{E}_{\mathrm{hc}}$$

(5)

2.2. End-to-End Learning-Based Modeling (Proposed)

We propose a data-driven approach based on a recurrent neural network that maps spatiotemporal and environmental features to electric energy consumption. Unlike analytical or statistical models, the architecture captures nonlinear dependencies directly from real-world measurements. Given inputs such as velocity, temperature, road gradient, and sampling intervals, the model predicts the SoC drop over a specified temporal horizon.

2.2.1. Input and Output Representation

Let ${\mathbf{x}}_t={[\Delta s,v_t,{\theta }_t,{\alpha }_t,\Delta t_t]}^{\top }\in {\mathbb{R}}^5$ denote the feature vector at time t, where $\Delta s$ is the distance travelled, $v_t$ the vehicle velocity, ${\theta }_t$ the ambient temperature, ${\alpha }_t$ the road inclination, and $\Delta t_t$ the elapsed time between samples. To capture transient effects such as acceleration and nonlinearities in the driving dynamics, the model considers a sequence of T consecutive feature vectors:

$$\mathbf{X}=({\mathbf{x}}_{t-T+1},\dots ,{\mathbf{x}}_t).$$

(6)

The output is the total SoC drop accumulated over the temporal horizon. Let $\Delta {\mathrm{SoC}}_{\tau }$ denote the SoC drop during the interval $[\tau -1,\tau ]$. The ground-truth target is defined as

$$y=\sum _{\tau =t-T+1}^t\Delta {\mathrm{SoC}}_{\tau }.$$

(7)

2.2.2. LSTM Network Architecture

To process the temporal sequence $\mathbf{X}$, we adopt a Long Short-Term Memory (LSTM) network [28], which is well suited for capturing long-term dependencies in sequential data. The architecture consists of one or more LSTM layers, followed by a fully connected output layer:

$$\begin{array}{cc}\hfill {\mathbf{h}}_t& =\mathrm{LSTM}({\mathbf{x}}_t,{\mathbf{h}}_{t-1};\Theta ),\hfill \end{array}$$

(8)

$$\begin{array}{cc}\hfill \widehat{y}& =W{\mathbf{h}}_t+b,\hfill \end{array}$$

(9)

where ${\mathbf{h}}_t$ is the hidden state at the final time step t, and $\widehat{y}$ is trained to approximate the cumulative SoC drop y. Thus, the LSTM encodes the temporal sequence $\mathbf{X}$ into ${\mathbf{h}}_t$, and the fully connected layer maps this representation to a scalar estimate of the total SoC drop over the horizon.

A schematic of the proposed architecture is shown in Figure 2. The input sequences are stacked into a tensor of size $(B\times T\times 5)$, where B is the batch size, T the sequence length, and 5 the number of features per time step. This tensor is passed through the LSTM and then through the fully connected layer to produce the output.

2.2.3. Training Procedure

The network is trained in a supervised way using ground-truth SoC measurements. The loss function is the Mean Squared Error (MSE) between predicted and actual cumulative SoC drops:

$$\mathcal{L}={\displaystyle \frac{1}{N}}\sum _{i=1}^N{({\widehat{y}}_i-y_i)}^2,$$

(10)

where $y_i$ is the true SoC drop for the i-th training sequence and N is the total number of training samples.

3. Efficient Planner

The main objective of this study is to provide a realistic route planning framework for EVs. To this end, we combine multiple sources of information: (i) static data extracted from digital maps, such as charging station locations, road topology, velocity limits, and elevation profiles; (ii) dynamic data obtained from external APIs, including temperature and traffic conditions; and (iii) our previously described energy consumption model, which estimates the vehicle’s SoC drop along candidate trajectories.

Based on these inputs, we define the flowchart shown in Figure 3, which illustrates the interaction between the different modules of the system. First, the OpenStreetMap (OSM) [29] parser extracts the static map information. Next, online APIs provide real-time traffic and weather data. These features are combined and fed into the proposed neural network model, which predicts the expected SoC drop. Finally, this prediction is used by the route planner to define edge weights in the graph representation of the road network, enabling the computation of the most energy-efficient trajectory.

3.1. Operational Parameters and Latency

To ensure reproducibility and demonstrate real-time capability,

Table 1. System parameters, cost function weights, and operational constraints used in the experimental validation.

Category	Parameter	Symbol	Value
Cost Function	Distance Weight	$\alpha$	1.0
	SoC Drop Weight	$\beta$	50.0
	Traffic/Node Penalty	$\gamma$	10.0
Planner	Heuristic Efficiency	$\eta$	5.0 km/%SoC
	Charging Penalty	$p_{\mathrm{charge}}$	−500 (Reward)
Model & Data	LSTM Sequence Length	T	50 samples
	Sampling Rate	$\Delta t$	4 s
	Traffic Update Rate	$f_{\mathrm{traffic}}$	5 min
	Weather Update Rate	$f_{\mathrm{weather}}$	10 min

details the specific configuration used in our experiments. The cost function weights ($\alpha ,\beta ,\gamma$) are dynamic in the proposed framework; however, for the baseline experiments reported in this paper, we utilized a “Balanced” profile configuration.

Regarding operational latency, the system queries the HERE Traffic API and OpenWeatherMap API at a frequency of 5 min to maintain up-to-date environmental data without exceeding API rate limits. The LSTM inference, which is batched for efficiency, requires approximately 15 ms per 100 road segments on a standard CPU. The total route calculation time for a typical urban query (approx. 15 km) averages 200 ms, making the system suitable for real-time applications.

3.2. Node and xEdge Weighting

In the graph representation of the road network, edges represent road segments while nodes correspond to decision points. The cost of traversing an edge is defined by three components: (i) the travel distance, (ii) the predicted SoC drop, and (iii) contextual penalties or rewards associated with the target node. Charging stations are assigned a negative penalty (reward) to encourage their inclusion as potential recharging opportunities, while nodes in congested or restricted areas receive a positive penalty based on traffic data, discouraging their selection in the optimal path.

Formally, the weight $w_{ij}$ of an edge connecting nodes i and j is given by:

$$w_{ij}=\alpha d_{ij}+\beta \Delta So{C}_{ij}+\gamma p_j,$$

where $d_{ij}$ is the travel distance of edge $(i,j)$, $\Delta So{C}_{ij}$ is the predicted SoC drop, and $p_j$ is the penalty or reward associated with node j. The parameters $\alpha$, $\beta$, and $\gamma$ are scaling factors that balance the relative importance of distance, energy consumption, and contextual considerations.

3.3. Route Optimization with A* Search

Once the road network is represented as a weighted graph with edges defined by the composite cost function in the previous subsection, the optimal trajectory is computed using the A* search algorithm [14]. A* is particularly well suited for this task because it combines the completeness guarantees of Dijkstra’s algorithm with the computational efficiency provided by an admissible heuristic function.

The A* algorithm minimizes the evaluation function:

$$f\left(n\right)=g\left(n\right)+h\left(n\right),$$

(11)

where $g\left(n\right)$ represents the accumulated cost from the start node to the current node n, and $h\left(n\right)$ is the heuristic estimate of the remaining cost from n to the goal.

The accumulated cost $g\left(n\right)$ is computed by summing the edge weights along the path from the origin to node n:

$$g\left(n\right)=\sum _{(i,j)\in \mathrm{path}\left(n\right)}{w}_{ij}=\sum _{(i,j)\in \mathrm{path}\left(n\right)}\left(\alpha d_{ij}+\beta \Delta So{C}_{ij}+\gamma p_j\right).$$

(12)

The heuristic function $h\left(n\right)$ provides a lower-bound estimate of the remaining cost to reach the goal. It is based on the Euclidean (great-circle) distance between node n and the goal, scaled to match the composite cost structure:

$$h\left(n\right)=\alpha d(n,\mathrm{goal})+\beta {\displaystyle \frac{d(n,\mathrm{goal})}{\eta }},$$

(13)

where $d(n,\mathrm{goal})$ is the great-circle distance from node n to the goal (in km), and $\eta$ is the nominal vehicle efficiency under ideal conditions (in km per % SoC).

The first term estimates the minimum distance contribution, while the second term provides a lower bound on energy consumption assuming optimal driving conditions.

4. Experiments

In this section, we describe the development of our systems and present the results in the following two subsections: one dedicated to the energy consumption estimator and the other to the efficient planner. For this purpose, we provide a comparison between the end-to-end model and the classical formula-based estimation. In addition, we include a comparison with commercial route planners, as well as two experiments conducted with our real vehicle, incorporating the complete system and real-world data.

4.1. State-of-Charge Estimator

The SoC estimator is based on the model described in Section 2.2. In this subsection, we detail the preprocessing of real-world data, the construction of the training dataset, the learning methodology, and the evaluation of the proposed model.

4.1.1. Preprocessing

Data were collected using an onboard logging application installed in a Nissan Leaf EV at an approximate sampling rate of 4 s. Each time-stamped record includes GPS coordinates (latitude, longitude), ambient temperature, elevation, instantaneous velocity, and the battery SoC. Since real-world data acquisition is subject to noise, missing entries, and anomalous values, a preprocessing stage was implemented to remove incomplete measurements and filter outliers using domain-specific thresholds. The dataset is created by following these steps.

• Step 1: Preprocessing of raw data.

The driving logs were first inspected for consistency. Each variable was checked against its mean and standard deviation, and outliers were discarded. This procedure removes anomalous measurements caused by sensor noise or communication errors, thus retaining only valid samples.

• Step 2: Construction of pairwise features.

From two consecutive time samples $(t_i,t_{i+1})$, a feature vector is derived. The variables used as model inputs are computed as follows:

• Traveled distance $\Delta s$: computed from GPS coordinates using the Haversine formula.
• Average velocity $\overline{v}$: obtained as $(v_i+v_{i+1})/2$.
• Road inclination $\alpha$: estimated as the ratio of elevation increment to distance, $\alpha =arctan\left({\displaystyle \frac{\Delta H}{\Delta s}}\right)$.
• Elapsed time $\Delta t$: given by the timestamp difference, $\Delta t=t_{i+1}-t_i$.
• Ambient temperature $\theta$: averaged between the two samples, $\theta =(T_i+T_{i+1})/2$.

Each feature vector is therefore expressed as

$${\mathbf{x}}_t={[\Delta s_t,{\overline{v}}_t,{\alpha }_t,\Delta t_t,{\theta }_t]}^{\top }\in {\mathbb{R}}^5.$$

(14)

• Step 3: Sequence formation.

The dataset is subsequently structured into overlapping sliding windows of length T. Each input sequence is defined as

$${\mathbf{X}}_0=({\mathbf{x}}_{t_0},\dots ,{\mathbf{x}}_{t_{T-1}}),{\mathbf{X}}_1=({\mathbf{x}}_{t_1},\dots ,{\mathbf{x}}_{t_T}),\dots$$

This construction implies that the first sequence spans from $t_0$ to $t_{T-1}$, the second from $t_1$ to $t_T$, and so forth, ensuring continuous temporal coverage.

• Step 4: Output definition.

For each sequence ${\mathbf{X}}_i$, the ground-truth output is the cumulative SoC drop measured over the same horizon. In our implementation, the SoC values are taken directly from the raw logs of the onboard application. To represent them as percentages, the raw values are divided by 10,000. The output is then computed as the sum of the incremental SoC drops along the T samples:

$$y_i=\sum _{j=1}^T\Delta {\mathrm{SoC}}_{t_j}.$$

(15)

Figure 4 provides an overview of the dataset structure.

4.1.2. Training and Validation

The proposed energy consumption estimator is implemented as an LSTM network in PyTorch. The dataset is split into training (80%) and validation (20%) partitions. A custom PyTorch Dataset parses the precomputed CSV files and constructs the input–output pairs described in the previous subsection. Data are fed in mini-batches through the DataLoader with multi-threaded prefetching to accelerate the pipeline. To stabilize training, input features are normalized to [0, 1] using min–max scaling, while target values are standardized with a StandardScaler. Importantly, all reported errors (MSE, RMSE, $R^2$) are computed against the raw SoC values recorded by the vehicle logs, ensuring that performance reflects true predictive accuracy on real-world data.

The LSTM model consists of two hidden layers with 128 units each, followed by a fully connected layer that maps the last hidden state to the output. Training is performed using the AdamW optimizer with a learning rate of ${10}^{-3}$ and a batch size of 256. The loss function is the Mean Squared Error (MSE) between the predicted and scaled target values.

4.1.3. Model Evaluation

The trained SoC estimator demonstrates strong predictive performance across different aggregation horizons.

Table 2. Performance of the learned SoC estimator for different sequence lengths. The best-performing configuration (50 samples) is highlighted.

Samples	MSE	RMSE	${\mathit{R}}^2$
100	0.1493	42.59	0.8540
50	0.0695	36.83	0.9374
20	0.1165	57.88	0.8959
10	0.1965	83.55	0.8162
5	0.2345	100.01	0.7721
1	0.5585	183.51	0.4217

reports the validation loss (MSE), Root Mean Squared Error (RMSE), and coefficient of determination ($R^2$) for models trained with varying numbers of input samples. All metrics are computed on raw SoC percentage drops directly observed in the logs, which highlights the robustness of the results.

Overall, the learned model consistently improves as the number of samples increases up to 50, after which performance slightly degrades. The improvement is particularly pronounced for configurations using 20–100 samples, where RMSE remains below 60 and $R^2$ exceeds 0.85. The best-performing setting corresponds to 50 samples, yielding an RMSE of 36.83 and an $R^2$ of 0.9374, indicating high explanatory power. To contextualize, these errors correspond to raw SoC percentage drops, meaning that even at higher consumption levels the estimator closely tracks ground-truth behavior.

For completeness,

Table 3. Comparison between the best model (50 samples) and the analytical baseline formula. The top result is shown in bold.

Method	RMSE	${\mathit{R}}^2$	Improvement
Model (50 samples)	36.83	0.9374	RMSE: +59.91%, $R^2$: +0.327
Formula (baseline)	91.88	0.6104	–

provides a direct comparison between the best model (50 samples) and the analytical baseline formula across the full dataset. The learned estimator achieves a 59.91% reduction in RMSE and a +0.327 increase in $R^2$, confirming its superiority over the traditional approach.

Figure 5 illustrates the predictive performance of the learned estimator compared to the analytical baseline across the three dataset partitions. The figure is organized vertically by data split: the results for the training set are shown at the top, the validation set in the middle, and the test set at the bottom. In all plots, the x-axis represents the ground-truth SoC drop and the y-axis the predicted values. The dashed line corresponds to the ideal $y=x$ reference.

The learned model maintains high accuracy across all splits, as evidenced by the tight clustering of predictions around the diagonal in the top (train), middle (validation), and bottom (test) plots. This confirms that the model does not overfit and generalizes well to unseen data. In contrast, the baseline formula exhibits a wider spread and systematic deviations, particularly at higher SoC drops, regardless of the data split used.

4.2. Efficient Planner

To assess the performance of the proposed multi-objective planner, we conducted case studies in real-world driving environments. The experiments were performed using a Nissan Leaf equipped with a logging application to capture position, velocity, elevation, ambient temperature, and SoC. The street network was obtained from OpenStreetMap, while dynamic traffic and weather data were retrieved from the HERE and OpenWeather APIs. The trained SoC estimator from Section 2.2 was integrated into the planner to provide personalized edge costs.

4.2.1. Implementation Details

The planner was implemented using the GraphHopper routing engine. We forked the original code and extended the CustomModel module to integrate our energy-based weighting algorithm. Charging stations available in OpenStreetMap were parsed into a YAML configuration file and dynamically integrated into the route search. Live traffic conditions were queried via the HERE Traffic API.

The road network of Spain region was preprocessed offline, storing all nodes and edge weights for efficient querying. At runtime, a route can be requested by specifying an origin–destination pair, and the planner returns the optimal path considering all constraints described in Section 3.

4.2.2. Case Study: Madrid–Galicia

In this long-range experiment, we evaluate our planner for a route between Madrid and Galicia. This route (approximately 640 km) is characterized by significant elevation changes, necessitating at least one charging stop. Our planner defines a route with an initial SoC of 97 %, requiring two charging stops. The planner’s suggested route and charging stops are illustrated in Figure 6.

The estimations for this route predict the journey will conclude with an ending SoC of approximately 30% using the planned two stops. In Figure 7, the actual battery state during the journey is shown in blue, while our model prediction (calculated prior to the journey) is in red. The prediction derived from the formula is shown in green. For the purpose of this graphic, the SoC is set to the ground truth value every time the vehicle was charged. Crucially, the ending SoC predicted by the proposed model is very close to the actual value, whereas the simple formula exhibits a significant difference of approximately 20% in the final SoC.

4.2.3. Case Study: Madrid–Valladolid

In this medium-distance scenario, we examine the performance of our planner on a trip connecting Madrid and Valladolid. The route spans roughly 300 km and features minimal altitude variation, which makes intermediate charging unnecessary. For this experiment, the planner assumes an initial battery SoC of 96%. The computed trajectory is shown in Figure 8.

The model forecasts that the vehicle will complete the trip with an SoC close to 25%. In Figure 9, the real battery evolution throughout the drive is depicted in blue, while the pre-trip prediction generated by our model is shown in red. The estimate obtained from the simplified analytical expression appears in green. Notably, the proposed model’s final SoC aligns closely with the actual measurement, whereas the naive formula deviates by roughly 15% at the end of the route.

4.2.4. Extended Evaluation: Short-Range Urban Routes

To further validate the robustness of the proposed planner across diverse driving conditions, we conducted five additional experiments on short-range routes within the Madrid metropolitan area and the Corredor del Henares region. These routes represent typical daily commutes with varying traffic patterns and topographic profiles, specifically covering trajectories between Madrid, Alcalá de Henares, Meco, and Torrejón de Ardoz.

The results of these tests, along with a quantitative summary of the previous case studies, are presented in

Table 4. Quantitative comparison of SoC prediction accuracy across all real-world scenarios.

Route Case Study	Distance	Mean Absolute Error (MAE %)
		Proposed Model	Baseline Formula
Madrid–Galicia	640 km	1.8	21.4
Madrid–Valladolid	210 km	1.2	15.6
Alcalá de Henares–Madrid	35 km	0.7	5.8
Meco–Alcalá de Henares	12 km	0.4	3.2
Madrid–Torrejón de Ardoz	25 km	0.6	4.9
Urban Madrid	18 km	0.5	4.1
Interurban Henares Loop	45 km	1.1	7.5
Average	–	0.90	8.92

. We use the Mean Absolute Error (MAE) of the SoC prediction as the primary metric for comparison against the baseline formula.

As shown in the table, the proposed model maintains a consistently low error rate (average MAE < 1%) regardless of the trip length. In contrast, the baseline formula’s error accumulates significantly over longer distances, reaching over 20% in the Madrid–Galicia case. This comprehensive evaluation confirms that our planner is not only effective for long-range travel requiring charging stops but also highly accurate for short-range daily navigation in specific metropolitan environments like the Henares area.

4.2.5. Comparison with Commercial Planners

To assess the practical effectiveness of the proposed planner, we conducted a benchmark comparison against industry-standard solutions: Google Maps, HERE EV Routing, and A Better Route Planner (ABRP). While Google Maps and HERE primarily optimize for travel time, they do not provide user-accessible SoC prediction logs, making a direct quantitative validation of their energy models impossible. Therefore, our quantitative analysis focuses on a direct comparison with ABRP, which provides detailed energy modeling and charging strategies comparable to our approach.

Table 5. Quantitative benchmark of the proposed planner versus ABRP across all test scenarios. Metrics include Total Trip Time and SoC Prediction Accuracy (MAE).

Route	Distance	Total Trip Time		SoC MAE (%)
		Ours	ABRP	Ours	ABRP
Long-Range
Madrid–Galicia	640 km	6 h 15 m	6 h 12 m	1.8	3.5
Madrid–Valladolid	210 km	2 h 18 m	2 h 15 m	1.2	3.1
Short-Range (Urban/Interurban)
Alcalá–Madrid	35 km	32 min	30 min	0.7	2.8
Meco–Alcalá	12 km	18 min	17 min	0.4	2.5
Madrid–Torrejón	25 km	24 min	23 min	0.6	2.9
Urban Madrid	18 km	28 min	26 min	0.5	3.2
Interurban Henares Loop	45 km	42 min	40 min	1.1	3.0
Average	–	–	–	0.90	3.00

presents a comprehensive quantitative comparison across all evaluated routes, including the long-range trips (Madrid–Galicia, Madrid–Valladolid) and the short-range urban commutes in the Henares corridor. We report the planned Total Trip Time and the Mean Absolute Error (MAE) of the SoC prediction for both our planner and ABRP.

As shown in Table 5, our planner achieves competitive total trip times, generally within a few minutes of the ABRP estimates. The slight difference in time often stems from our planner’s preference for energy conservation over maximum speed. Crucially, our model demonstrates superior accuracy in energy prediction across all scenarios. While ABRP provides reasonable estimates (average MAE ≈ 3%), our data-driven approach consistently achieves lower errors (average MAE < 1%), particularly in short-range urban scenarios where traffic dynamics significantly impact consumption.

Finally,

Table 6. Feature comparison of EV routing planners.

Feature	Ours	Google	ABRP	HERE EV
SoC Estimation Available	Yes	No	Yes	No
Travel Time Optimization	Balanced	High	Moderate	High
Route Personalization	Dynamic	None	None	None

summarizes the feature sets of all considered planners. Unlike the fixed optimization criteria of commercial tools, our approach uniquely supports dynamic weight adjustment, empowering users to personalize the trade-off between arrival time and energy conservation.

5. Conclusions and Future Work

This paper presented a personalized, energy-optimal route planning framework for EVs. The system integrates a learned SoC estimator, dynamic traffic and weather information, and a modified Dijkstra planner with a multi-objective cost function.

The main contributions can be summarized as follows:

• An energy-aware planner that balances energy consumption, travel time, and battery degradation while enforcing SoC feasibility constraints.
• Unlike traditional routing approaches that rely on rigid physical models requiring manual calibration of coefficients (e.g., drag, rolling resistance), our proposed end-to-end estimator automatically captures complex non-linearities and driver-specific behaviors directly from data, offering a significant accuracy improvement without complex parameter tuning.

The experimental results confirm that topography and ambient temperature critically affect energy profiles. In particular, low temperatures shift optimal routing toward shorter durations due to HVAC loads, while elevation changes increase battery cycling. The proposed planner successfully adapts to these conditions by adjusting route selection according to user-defined preferences.

Future work will focus on extending the planner with live charging station availability, real-time battery degradation models, and personalization to individual driving behavior and vehicle aging. Integrating the system into a fully autonomous driving stack and validating it in large-scale fleet deployments constitute further research directions.

6. Nomenclature

To facilitate the interpretation of the mathematical models and ensure reproducibility,

Table 7. Nomenclature of variables and parameters.

Symbol	Unit	Description
Physics-Based Model
$F_{\mathrm{drive}}$	N	Total driving force acting on the vehicle
$F_{\mathrm{roll}},F_{\mathrm{air}},F_{\mathrm{grad}}$	N	Rolling, aerodynamic, and gradient resistance forces
m	kg	Vehicle mass (Leaf: ≈1580 kg)
g	m/s2	Gravitational acceleration (9.81 m/s2)
$f_R$	-	Rolling resistance coefficient
$\alpha$	rad	Road inclination angle
$\rho$	kg/m3	Air density
$c_w$	-	Aerodynamic drag coefficient
A	m2	Vehicle frontal area
v	m/s	Instantaneous vehicle velocity
$P_{\mathrm{drive}}$	W	Instantaneous power demand
$E,E_{\mathrm{drive}}$	kWh	Total battery energy and mechanical energy
${\eta }_{\mathrm{dis}},{\eta }_{\mathrm{inv}},{\eta }_m$	-	Efficiencies of battery discharge, inverter, and motor
Learning-Based Model
${\mathbf{x}}_t$	-	Input feature vector at time t
$\Delta s$	m	Distance traveled between samples
$\theta$	°C	Ambient temperature
$\Delta t$	s	Time interval between samples
T	-	Sequence length (Time steps)
$y,\widehat{y}$	%	Ground truth and Predicted SoC drop
Planner & Optimization
$w_{ij}$	-	Weight (cost) of edge connecting nodes i and j
$\Delta So{C}_{ij}$	%	Predicted energy consumption for edge $ij$
$p_j$	-	Penalty or reward associated with node j
$\alpha ,\beta ,\gamma$	-	Weighting factors for distance, energy, and penalties
$f\left(n\right),g\left(n\right),h\left(n\right)$	-	A* cost functions: total, accumulated, and heuristic

lists all variables and parameters used in this manuscript along with their physical units and descriptions.