What is D2EV?

Kaluza is building the zero-carbon energy systems of the future, and our Flex platform enables the smart controlling of a range of low-carbon electric devices. By controlling the charging of these devices, we can optimise to charge at times when there are lower energy prices and lower carbon emissions from the grid. One of the most common devices that we control are smart chargers for Electric Vehicles. Instead of charging as soon as an Electric Vehicle (EV) is plugged in, we create optimised charging schedule based on price and carbon forecast. We dispatch the schedule to the smart chargers to control their behaviour. In order to do this, we ingest telemetry from, and dispatch commands to, the smart chargers which are installed directly in our customers’ homes. Whilst powerful, controlling an EV’s charge using smart chargers does have a number of drawbacks:

1. We can only optimise charging for users who have purchased specific smart chargers
2. Smart chargers do not give us the EV’s state of charge - a highly important metric for ensuring that a vehicle is fully charged when needed
3. Not all EVs will pause charging when instructed to do so via the smart charger
   

Direct to Electric Vehicle (D2EV) is a different technology platform for controlling EV charging which bypasses the smart charger altogether. It allows us to get telemetry and dispatch commands directly to and from the EV itself, without having to know anything about the charger. D2EV works by using our own Flex internal services to communicate with the car manufacturer's customer API. Whilst this comes with its own challenges, it allows us to gain accurate state of charge data and to serve a greater range of customers, regardless of which charger they have installed.

How can D2EV help us to reach net zero?

As mentioned in our previous article, increasing the number of EVs that we can optimise will help us have bigger impact on the grid and advance Plan Zero. D2EV gives us more control over the charging of EVs, enabling us to precisely pause and resume charging according to the state of the grid and the customer’s requirements. This precision allows us to generate even more value, which could be passed on to EV drivers in the form of lower energy costs; lowering the cost of ownership is one of the key challenges in getting more drivers to make the switch from internal combustion engine vehicles to EVs.

Our D2EV tech stack

At Kaluza we use Kafka as a backbone, so nearly all communication between our services is done through publishing events. This means that our platform mainly interacts with other agents via events. From a technical perspective, the only thing we needed to do for D2EV was to connect the different actors (users, OEM applications) with our platform.

In order for the Flex platform to successfully generate schedules and optimise according to energy prices and carbon emissions, we require the following data:

• Telemetry from the EV (e.g. state of charge, cable state, charge mode). In our domain we call this the ingestion pipeline
• A way to dispatch the schedules generated by our platform to the EV. We call this the dispatch pipeline
  

The first problem to solve was how users would interact with our platform and allow it to optimise their EVs. We needed a way for our users to link their OEM (Original equipment manufacturer) account with our platform, and be able to set preferences such as “Ready-by time”.

In order to enable that, we decided to create a Flutter app for both Android and iOS. We used the Firebase platform to build a bridge between the user and our services, that way the mobile application is only interacting with Firebase and isn’t aware of our backend services. Firebase offers a few out of the box solutions, such as Firesore, Authentication and Google Analytics, which saved us precious dev time, and allowed a secure bridge between the frontend and our platform.

Registration

To onboard a user, we designed the following core process:

1. The user downloads the app
2. The user logs in and authenticates with our platform using Firebase authentication
3. We allow the user to authenticate their EV, enabling us to ingest telemetry and dispatch commands
4. We generate a registration event on Cloud Firestore
5. We use Cloud Functions to push this event to a Kafka topic
6. Our registration service listens to the event and registers the EV with the platform
   

Telemetry

The telemetry pipeline is listening for new registrations. Each time that we onboard a new EV on the platform, we start fetching telemetry for that particular EV and publish telemetry events to the platform.

Control

The dispatch pipeline is listening for control schedules generated by the platform, and contacts the OEM API to instruct the EV on the best time to charge.

Info and notifications

Now that we can receive telemetry and send schedules, we need to inform the user about what is happening with their EV charging. For that, we created a service that extracts charging information from the platform, and stores the results in Cloud Firestore. This way, when the user wants to know what is the current status of their EV, the application only has to query Cloud Firestore.

Reflections on our event-driven microservices approach

Designing for rapid integrations with other EVs

As a starting point for our D2EV platform, we integrated with a single car manufacturer, this let us focus on fewer cases to handle. Nevertheless, we made a strong design decision to make our D2EV microservices as OEM agnostic as possible. When we had completed a successful design, implementation and testing of our D2EV platform with a single OEM, we decided to extend our Beta by adding an additional OEM. Due to our design approach, integrating with the new OEM took us less than a quarter of the time it took to integrate with our first OEM. Having a solid design in place, which is OEM agnostic, allows us to add a limitless number of integrations with extremely minimal additional development time.

Events driving valuable user feedback

We know from our user research that EV drivers care about charging and want to know how much charge their vehicle has at all times. When it comes to smart charging, in which the vehicle will not always start charging as soon as it is plugged in, we have discovered that users are reassured by a notification at plugin that provides an estimated charging start time. Given the event-driven nature of our platform, we are able to tap into existing plug-in and schedule notifications to create a push notification which can be dispatched to both our native Android and iOS apps via our backend. This way our users are informed as soon as we have calculated their scheduled charge start time.

Unleashing the power of Kubernetes and Go

Our technologies of choice worked extremely well for the D2EV application. Writing our services in Go allowed us to write neat, focused and foolproof microservices which addressed each of the many moving parts of our architecture, this enabled great velocity, quality, readability and maintainability. With kubernetes we were able to allocate resources and make changes and on-the-fly experiments affecting only specific and necessary components in our pipeline. Using well designed Go services, which separated our OEM interactions from our platform logic, we unlocked the potential to spin up a pipeline and run it with an OEM “head” of our choice, hence enabling rapid onboarding of new OEM integrations.

The D2EV offering is a fresh and exciting tech challenge to take part in. There are still many challenges to explore, especially with regards to ways in which different OEM APIs operate. Nevertheless, the potential embedded in D2EV-driven optimization is vast, especially within the area of smart homes, carbon efficiency and energy prices. We are hoping to share more exciting news and lessons about this in the near future, and as part of our Plan Zero.