Electric Vehicle Features in the HERE SDKs for Android, iOS, and Flutter

It’s been over a year now since the release of the latest version of the HERE SDKs for iOS, Android, and Flutter. Since then, more cool new features and capabilities have been added. Today I want to highlight some of those features, specifically those focused on use cases for electric vehicles.

In this blog post we will look at how to:

• Use the routing feature for electric vehicles
• Determine the reachable area of an electric vehicle given a remaining range or battery charge
• Search for charging stations along a route

Before we get started, I want to point out that you can see all of these features in action in our “EVRouting” example in on GitHub. Go ahead and grab this for a running demo plus full code of everything we will be talking about below.

Electric Vehicle Routing

Let’s get started with the Routing API. A call to the Routing API in EV mode is fundamentally the same as any other call to the Routing API, except that we are using an EVCarOptions object to define the vehicle parameters. This does turn out to be a little more involved than usual, as there are quite a few parameters we can set.

Here’s an example for setting the parameters in EVCarOptions. (Note that this example is for Android, but all the features discussed here are also available on the HERE SDKs for Flutter and iOS.)

The first three parameters are required to make any EV routing call. The free flow table defines the energy consumption of the vehicle as a curve using pairs of speed (km/h) and consumption (Wh/m) values. In addition, the ascent consumption and descent recovery values indicate what effect inclines have on the battery (in Wh/m).

By default, the Routing API will assume that you have enough charge to reach any given destination. Given that range anxiety and charging infrastructure are still issues, we may also want to take the vehicle’s battery charge and the location of compatible charging points into account. That is when things get interesting when you turn on ensureReachability. With this parameter, the Routing API will automatically route you to charging points where necessary and even take the charging time into account when calculating arrival time. Neat!

However, when using this feature, you must provide some additional parameters. These include the total capacity of the battery (in kWh), the charging connector types available on the vehicle, and a battery charging curve. This curve is provided as a list of charging rate (in kW), charge level (in kWh) pairs. In addition, you must provide an initial charge level and a target charge level. These are the respective battery charge levels at the first and last waypoints. (Providing a target charge level ensures you don’t strand your users at their destination with an empty battery.)

Check out the SDK documentation for full details on these parameters. The API Reference of the underlying Routing REST API can also be helpful.

EV Reachability

The range of EVs remains a major concern, both when purchasing and using electric vehicles. The Isoline Routing feature of the SDKs allows you to calculate the area an EV can reach given a current battery level.

Let’s say you are in the city centre of Berlin and you want to calculate which area you can potentially reach with an energy budget of 400 Wh. Once again, using Isoline Routing based on battery charge is very similar to making a standard Isoline Routing call. In fact, you can check out my recent blog post on Isoline Routing with Android for details on how to do this. The only thing we need to change is the range type in the calculation options and provide an appropriate value for battery charge. Here’s a complete example of how to call the Isoline Routing feature with a consumption-based range type.

Note that this example shows how to visualise the reachable area on the map, however you can also use the result to match the area against a list of possible customers in a delivery use case, to find charging stations inside the area, and much more.

Charging Stations along a Route

As we’ve seen above, the Routing API will automatically search for charging points along a route and even integrate them into the route for you if necessary. However, what if we have a given route and want to search for charging points manually? That is where the Search feature of the SDK comes in handy. In addition to searching near a given location, or within a bounding box, it also allows us to search along a GeoCorridor. This corridor can be defined by a GeoPolyline and a radius (in metres). Of course, this is useful for everything from gas stations to restaurants, but in the example below we will search for charging points.

First, we define a GeoCorridor by providing our route as a polyline (which we could get from the Routing API or any other data source) and the search radius of 200m. This means that we will only search for results which are no more than 200 metres away from our route. Then we simply provide this corridor as a search area for a TextQuery and make a normal search request using this query.

I’ll close with another reminder to check out the “EVRouting” example on GitHub. Also check out our Routing API Demo Client. While this uses the underlying REST API and not the SDK directly, it is a great way to experiment with the various charge and battery parameters, visualise the curves, and see how they affect the routing results.

A reminder that Grey Matter is a HERE Distributor and can help you with your use case, get you set up with an eval and provide licensing advice. Contact them directly: here@greymatter.com / +44 (0)1364 655 133.