EV Routing

Introduction

The Navigation system provides a suite of Electric Vehicle (EV)-specific features designed to enhance the driving and charging experience. Key capabilities include:

• Searching for nearby charging stations.
• Displaying estimated driving range directly on the map.
• Automatically planning charging stops along the route.

This document is intended for both external and internal integrators of NavSDK and Automotive UI in EVs. It provides:

• An overview of the Long Distance EV Routing (LDEVR) product
• Details on required data formats
• Key assumptions and limitations
• Guidelines for integrating LDEVR with the Battery Management System (BMS)

Overview

Long-Distance Electric Vehicle Routing (LDEVR) is a navigation system feature that automatically suggests charging stops when an electric vehicle (EV) driver plans a route that exceeds their vehicle’s range. LDEVR optimizes both the route and charging stops based on the vehicle’s battery level and charging capabilities. This removes the need for drivers to manually plan their charging stops and offers the charging destination efficiently.

By providing a charging plan both before and during the trip, LDEVR also delivers accurate estimates for total travel time (ETT) and expected arrival time (ETA).

Estimated Travel Time (ETT) and Estimated Time of Arrival (ETA)

By planning charging stops into the trip instead of ad-hoc charging, the car can also automatically pre-condition the battery for Direct Current (DC) fast charging and the driver can see updates about their upcoming stops in the navigation system. Drivers are provided with suggested charging times and SoC changes (from X% to Y%) based on the capabilities of the charging station and vehicle. For more information, refer to the Nominal battery capacity section.

Fully automatic versus manual EV route planning

TomTom provides the option to enable or disable EV routing to users, with the default set to “on”. When this setting is active, charging stops are suggested at the planning stage for out-of-range destinations, but will also be suggested when a driver’s battery SoC will not allow them to reach their destination within preset SoC buffer values. For more information, refer to the Recommended default SoC values section. Drivers can also change a suggested charging stop or add a different charging stop to a route using Search functionality. When this is done, the remaining route, including all originally planned stops, will be adjusted to reflect the new location.

Whether a destination is inside or outside the range of the vehicle is determined using TomTom’s own consumption model, which uses vehicle parameters and signals to calculate the distance a vehicle can drive based on attributes present in the map. The following sections provide more details about the vehicle parameters used in this model.

EV Routing system context and data flow

The accuracy and effectiveness of EV navigation features rely on the integration between the Navigation system and the vehicle’s Battery Management System (BMS). The level of integration can range from a simple integration where the BMS provides information about the battery's State Of Charge (SoC), the charging curve, consumption curve, and supported charging connectors to more advanced information such as battery conditioning energy consumption, driving condition-dependent consumption curves, and temperature-dependent consumption curves.

The diagram below provides a simplified representation of the various systems involved in LDEVR. The EV Battery Management System is responsible for providing all necessary battery information, enabling Navigation to perform LDEVR. This includes data such as the state of charge, maximum battery capacity, charging curves, and more. This information is typically provided via the In-Vehicle Infotainment (IVI) system and used by the Navigation system, or it can be obtained via the OEM Connected Car Cloud and used by a Companion App.

The OEM Connected Car Cloud is a system designed to provide vehicle data or functions to systems outside the vehicle's context. The name of this system may vary across different OEMs.

OEM Connected Car Cloud

The Navigation system or Companion App can request the Online Routing API to calculate an LDEVR route because it has all the necessary battery information retrieved from the IVI system or OEM Connected Car Cloud.

The format and behavioral aspects of the retrieved battery information may not match what is expected for the correct behavior of LDEVR. The next chapter describes the required inputs.

The required inputs can be supplied through various APIs, depending on the integrator role. However, the semantics of the input remain unchanged. The APIs are explained in section LDEVR integration guide | Navigation system API requirements.

Consumption model inputs

The navigation system must accurately predict energy consumption along the route to estimate the State of Charge (SoC) upon arrival, display the range on a map, and automatically incorporate necessary charging stops. To achieve reliable consumption estimates, several parameters are essential. It is important to note that some of these parameters serve additional functions; for example, the vehicle's weight will also be used to avoid roads with weight restrictions during routing.

Consumption model overview

Parameter stability

Most vehicle parameters can be dynamically adjusted during a trip. However, the selection and automatic addition of charging stations along a route is highly sensitive to these parameters. Typically, charging stations are chosen to ensure that the State of Charge upon arrival is just above a configurable threshold. If parameters change after this selection, it may render the station unreachable, necessitating a recalculation of the route with different charging stops.

Conversely, if the parameters shift in the opposite direction, the original charging stops might become viable again, resulting in an inconsistent user experience. For a good user experience, it is crucial that parameters remain stable throughout the trip, particularly avoiding short-term spikes. Even in scenarios without automatically added charging stops, drivers may experience fluctuating predicted State of Charge at arrival, which can create an impression of unreliability. For instance, fluctuations in current battery capacity of 5% during a trip can contribute to this perception (see Current battery capacity section).

List of parameters

The following parameters are relevant:

• Nominal battery capacity
• Current battery capacity
• State of Energy (SoE)
• Consumption curve
• Auxiliary power
• Weight
• Efficiency
• Charging curve
• Charging connectors

The following table details the required Android properties along with a reference to the parameter used when only using the Online Routing API.

Parameters

Nominal battery capacity

The maximum amount of energy, measured in watt-hours (Wh), that can be extracted from the battery at 20°C and is available for propulsion, thermal management of battery, and auxiliary power (such as HVAC systems) is a fixed value specific to each car model.

This maximum extractable energy does not include any energy permanently reserved in top/bottom buffers to protect battery longevity. Internal battery losses, i.e. energy lost before reaching the inverter due to Ohmic heating, electro-chemical side losses etc., should be already deducted. Also aging effects of the battery (State of Health) should already be considered.

However, it does include all powertrain consumption, including losses incurred in the power inverter.

Current battery capacity

The battery capacity, measured in watt-hours (Wh), reflects the vehicle's current capacity after accounting for aging and considering the State of Health. Typically, the battery experiences a capacity loss of 2–3% per year. This value must remain within the range [0, nominal_battery_capacity].

This value must remain stable throughout the duration of a trip. Specifically, it should not account for efficiency variations due to the current battery temperature; instead, it should refer to the energy available at a battery temperature of 20°C.

This approach ensures consistency, as battery temperature can fluctuate significantly during the trip, necessitating a common baseline for battery capacity across all charging and operational events along the route. Acceptable small fluctuations, such as those less than 0.3% over the course of a trip due to updated State of Health, are permissible. Larger fluctuations can negatively impact user experience (see the Parameter stability section). Additionally, changing battery capacity can cause wrong estimates of the charging time, since the charging curve (see Charging curve) assumes a constant battery capacity.

State of Energy (SoE)

The current amount of energy, measured in watt-hours (Wh), that can be extracted from the battery at a temperature of 20°C and is available for propulsion, battery thermal management, and auxiliary power. This value must fall within the range [0, current_battery_capacity].

Updates should occur at a frequency of 1 Hz, and the rate of change should be as smooth as possible (refer to the Parameter stability section). Fluctuations caused by thermal effects—rather than consumption or charging—should remain below 0.3% over the course of a trip.

The SoE must be consistent with the battery capacity, which means that:

• It does not account for internal battery losses
• It does not consider reserved energy, ensuring that both 0 and current_battery_capacity are reachable values
• It is independent of the current battery temperature

The SoE should linearly map to the State of Charge in percent as displayed to the driver, i.e.:

• An SoE of 0 kilowatt-hour (kWh) corresponds to an SoC of 0%
• An SoE of current_battery_capacity kilowatt-hour (kWh) corresponds to an SoC of 100%

Consumption curve

The consumption curve represents the energy required to travel 100 km while overcoming air and rolling resistance, varying with speed under ideal conditions. This parameter is crucial for providing accurate consumption estimates and must be updated whenever conditions change that affect factors like rolling resistance, such as an increase in weight.

The following example represents a consumption curve with points (10:11.41), (20:9.17), (30:8.77), (40:8.95), (50:9.48), (60:10.26), (70:11.26), (80:12.46), (90:13.85), (100:15.43), (110:17.19), (120:19.13), (130:21.25), (140:23.55), (150:26.02), (160:28.66), (170:31.48), (180:34.48), (190:37.65), (200:40.99):

Consumption curve

The consumption includes all internal losses, such as those from transmission, load-dependent inefficiencies of the motor, and losses in the power electronics (inverters). However, no additional sources of consumption should be considered such as energy used for auxiliary power or battery preconditioning. The consumption curve applies to a route characterized by:

• No acceleration or deceleration
• No slopes
• An ambient temperature of 20°C, with no adverse weather conditions like wind or rain

The curve should be defined by 15 to 25 points, roughly evenly spaced from 10 km/h to the vehicle's maximum speed. Values between these points will be linearly interpolated, while values before the first point and after the last point will be linearly extrapolated. It is important to ensure that this linear extrapolation does not yield a negative consumption value at any positive speed.

Ideally, this curve is determined by drive tests with a controlled scenario (no acceleration or deceleration, no slope) at various speeds. If this is not available, an alternative is a rough estimate based on vehicle parameters such as weight and drag area. TomTom provides a script that can help with this.

The consumption curve is the most important parameter for consumption estimation, so errors will have a large effect (e.g. if the curve points are 10% too low, consumption estimation will be almost 10% too low). Thus, it is the best place to focus efforts to improve the consumption parameters.

The routing system adjusts the consumption curve to account for changes in air resistance due to temperature (this is why the curve should be provided for a fixed temperature). It does this online using TomTom's weather service to predict the temperature and onboard by using the ambient temperature sensor value. Thus, to improve consumption prediction for the offline case, it is recommended to always provide the ambient temperature signal.

In an upcoming feature, TomTom will offer automatic correction of the consumption curve based on telemetry data from the vehicles, but this is not available yet.

Auxiliary power

This represents the expected average auxiliary power for the remainder of the trip. It may fluctuate during the journey, for instance, if the air conditioning settings are adjusted. It encompasses all non-motor, non-drivetrain, and non-battery-related consumption, such as climate control systems, infotainment systems, and lighting systems.

This value can be estimated based on the measured current auxiliary power use. For this, the parameter should not reflect instantaneous power to avoid fluctuations that lead to replanning (see the Parameter stability section). Rather, we recommend providing the average power consumption over the past 5 minutes. Alternatively, a prediction (for example based on ambient temperature) can be used to estimate the future auxiliary power. If neither measured auxiliary power nor an estimate are available, a default of 500 W can be used.

For this parameter, only larger errors matter; e.g. if the auxiliary power is actually 800 W instead of 500 W, the consumption prediction error is about 2%; if the auxiliary power is actually 2000 W (e.g. when using air conditioning at high heat), the error is about 10%.

Weight

The total weight of the vehicle measured in kg, includes passengers, cargo, and any additional installed equipment.

If the vehicle is equipped to dynamically estimate its weight, it is recommended to update this value to improve consumption prediction accuracy. However, it is important to note that adjusting the weight after departure—such as when it takes a few minutes to gather sufficient data for estimation—can result in the need to replan charging stops, particularly if there is a significant weight difference (e.g., 400kg weight increase for a delivery vehicle could increase consumption by 5–7%).

Efficiency

The following parameters are required:

• Acceleration efficiency: efficiency of converting electric energy to kinetic energy when the vehicle accelerates (i.e., KineticEnergyGained/ElectricEnergyConsumed), in %.
• Deceleration efficiency: efficiency of converting kinetic energy to electric energy when the vehicle decelerates (i.e., ElectricEnergyGained/KineticEnergyLost), in %.

Note: These values may depend on both the initial and final speeds during an acceleration or deceleration process.
They should be provided for a typical maneuver, such as from 60 km/h to 80 km/h.

• Uphill efficiency: efficiency of converting electric energy to potential energy when the vehicle gains elevation (i.e., PotentialEnergyGained/ElectricEnergyConsumed), in %.
• Downhill efficiency: efficiency of converting potential energy to electric energy when the vehicle loses elevation (i.e, ElectricEnergyGained/PotentialEnergyLost), in %.

Note: These values may depend on both the initial speed and the slope.
They should be specified for a typical scenario, such as a 2% slope at 80 km/h.

The uphill and downhill efficiency values are independent of the current vehicle weight, so they do not require updates when the weight changes. Their relationship to the energy consumed per kilometer of elevation gain (EUphill) and the energy recovered per kilometer of elevation loss (EDownhill) is as follows:

Uphill and downhill efficiency formula

If these values are unavailable, a default value of 90% can be used.

Charging model inputs

To estimate the time spent at charging stations, allowing to minimize the overall ETT, several more parameters are needed.

Charging curve

This is a piecewise-constant function that maps the State of Energy (SoE) to the maximum charging power supported at that SoE, assuming a battery at optimal temperature for charging (20°C). It is used to calculate charging time. The curve is defined by up to 20 pairs of SoE and corresponding power values. For a specified power at a given SoE, that power applies from that SoE value up to the next specified SoE in ascending order. Below the first specified SoE value, the power from the first specified SoE is used.

The charging time calculation does not consider battery temperature, as it is assumed that the battery is preconditioned (refer to "Battery Preconditioning"). If the charging curve is not known from measurements, a typical curve can be used:

• 0–10% SoC: 50% of peak power
• 10–50% SoC: 100% of peak power
• 50–80% SoC: 75% of peak power
• 80–90% SoC: 35% of peak power
• 90–100% SoC: 20% of peak power

Example of charging curve

However, charging curves can vary a lot; for instance, some LFP battery packs start tapering off already at 20% SoC. Relying on this default could mean that the charge time predictions are off by 50% in edge cases.

Charging connectors

For additional information refer to Charging parameters.

Note that the list of connectors can be used not only to model different physical connectors, but also to model other constraints.

Example of a vehicle capable of charging only at native pack voltage

This is modelled through one connector with open voltage range:

1"chargingConnectors": [
2  {
3    "currentType": "DC",
4    "maxPowerInkW": 100,
5    "maxVoltageInV": 355,
6    "voltageRange": {
7      "minVoltageInV": 355,
8      "maxVoltageInV": 0    # this means no limit
9    },
10    "plugTypes": [ ... ]
11  },
12]

Example of split-pack/series-pack configuration

Some vehicles have a low voltage battery pack that can be reconfigured in series for high power charging.

Alternatively, some models use a high voltage pack that can be used in a split-pack configuration for low voltage charging.

1"chargingConnectors": [
2  {
3    "currentType": "DC",
4    "maxPowerInkW": 160,
5    "maxVoltageInV": 400,
6    "voltageRange": {
7      "minVoltageInV": 400,
8      "maxVoltageInV": 800,
9    },
10    "plugTypes": [ ... ]
11  },
12  {
13    "currentType": "DC",
14    "maxPowerInkW": 350,
15    "maxVoltageInV": 800,
16    "voltageRange": {
17      "minVoltageInV": 800,
18      "maxVoltageInV": 0    # this means no limit
19    },
20    "plugTypes": [ ... ]
21  },
22]

Example of DC-DC converter equipped vehicle

Some vehicles, e.g. E-GMP and the J1 platform, are equipped with a high voltage battery pack and a DC–DC converter enabling use of low voltage stations. In this case voltageRange.minVoltageInV for the lower power “connector” is not related to the battery pack voltage, but indicates the minimum voltage accepted by the converter.

1"chargingConnectors": [
2  {
3    "currentType": "DC",
4    "maxPowerInkW": 100,
5    "maxVoltageInV": 423,
6    "voltageRange": {
7      "minVoltageInV": 400,
8      "maxVoltageInV": 697,
9    },
10    "plugTypes": [ ... ]
11  },
12  {
13    "currentType": "DC",
14    "maxPowerInkW": 263,
15    "maxVoltageInV": 697,
16    "voltageRange": {
17      "minVoltageInV": 697,
18      "maxVoltageInV": 0    # this means no limit
19    },
20    "plugTypes": [ ... ]
21  },
22]

Recommended default SoC values

The Navigation system uses a set of configurable values for different parts of the LDEVR experience.

It is recommended to adjust the default SoC buffer (MinCharge) values based on the effective range of the vehicle to create a consistent experience for all drivers. With these adjustments, models with larger battery packs or improved efficiency will have a similar distance remaining at arrival based on their set SoC buffer values. Any adjustments should be validated under real-world conditions to ensure the desired driving experience is achieved.

Default charging stop parameters

The following default parameters when calculating the minimum time needed for a charging stop.

Navigation system API requirements

This section describes the mapping of the aforementioned parameters to the Navigation system APIs. The mapping depends on the integrator role, NavApp, NavSDK or Online Routing API.

I’m an Online Routing API integrator

The Long Distance EV Routing | Long Distance EV Routing API must be used for LDEVR. The following table describes the parameter mapping on the API.

I’m a NavSDK integrator

The API reference | Navigation SDK for Android must be used for LDEVR. The following table describes the parameter mapping on the API.