Kia EV6 Telematics Dashboard [CAN Bus & UDS + DBC + Grafana]

Specifically, I leveraged information from an open source github project to create a CANedge2 Configuration File with a list of 'transmit messages' that would trigger certain responses from the Kia EV6. This involved using UDS multiframe requests with every request frame followed by a flow control frame. For details, see our intro to UDS and the actual Configuration File in the data pack (see below).

I configured the CANedge2 to connect to my iPhone as an access point via WiFi - and upload data to my AWS S3 bucket. This way, whenever I would enable my shared WiFi on my phone in the car, data would get uploaded by the device to the server.

Note: Since this case study, we also released the CANedge3, which simplifies this work flow by enabling direct upload to S3 via 3G/4G.

To install the device, I initially just connected it to the OBD2 connector (beneath a panel near the steering wheel) using our OBD2 adapter cable. This works perfectly well, but has the downside that the device remains powered (and transmitting) when the EV is turned off. The EV6 does not provide any 'default broadcast data' via the OBD2 connector, meaning a control signal cannot be used to start/stop the transmission of data into the car - meaning that ECUs could be woken up and the battery would be drained within a few days. To solve this, I modified my installation to use a cigarette-receptacle adapter and a DB9-DC splitter. This ensures that the CANedge power supply is linked to the vehicle ignition, thus avoiding any risk of battery drainage.

An alternative way that I also tested was to use the CANedge 'control signal' to start/stop transmission based on the GPS-based vehicle speed. This way I could stop transmission when the vehicle was standing still. This reduced the cables required, though also implied that I would not get data during e.g. red lights or traffic queues.

In order to add GNSS/IMU data to the log files from the Kia EV6, I originally also connected the CANmod.gps to the 2nd port of the CANedge2. The CANmod.gps would then be installed within the vehicle via 3M velcro tape so as to ensure a stable installation during driving. As part of this, I measured the CANmod position in the car to adjust the configuration of the device. This in turn lets me leverage the sensor fusion capability of the CANmod.gps (providing precise positioning even in GNSS hostile areas), as well as adding valid data on e.g. the car's attitude (roll, pitch, yaw).

Note: In 2024, we updated the dashboard playgrounds to re-map the CANmod.gps data as if coming from an internal CANedge GPS/IMU, since this is now the most common and low cost way of adding this data to your log files.

A key signal displayed in the Kia EV6 is kWh / 100 km, serving as a measure of your ability to drive efficiently. The Kia EV6 range of ~500 km is based on an assumption of ~15 kWh / 100 km (est. 74 kWh capacity). As such, adding this parameter to my dashboard would be insightful.

One challenge, however, is that the kWh / 100 km is not an available signal from the github resource. In other words, I had to calculate it as a derived signal.

This can be done by creating two Athena queries in a single panel:

1. The first returns a custom signal, Watt, calculated by multiplying Current and Voltage and taking the average. It is important not to take the average of Current and Voltage before multiplying, due to the non-linear nature of the kWh/100km formula
2. The second extracts average Speed in m/s from the GPS/IMU

With these values, we can then use Grafana Transformations to create a calculated signal, kWh100km, equal to (Watt / Speed) * 0.027777778, with the factor being related to the fact that we're measuring speed in m/s.

At a later stage in my analyses, I decided to create a 'custom Parquet table' containing both Current, Voltage and Speed. This in turn enabled me to simplify the panel. However, you can still find similar multi-query kWh/100km examples in the other EV dashboard playgrounds.

Our default 'trip aggregation' methodology enables trip aggregations that involve a single CAN signal (e.g. average of speed, max of temperature). This can be easily extended with 'custom aggregations' to also support functions based on multiple signals in the same CAN message aka Parquet table.

However, the default aggregation methodology does not easily support cross-message signal calculations, which is required by default to calculate kWh/100km as a custom signal.

Luckily, another 'advanced feature' of the Grafana-Athena integration enabled me to create 'custom signals' in a simple manner. Specifically, I created a custom table with Current, Voltage and Speed resampled to a 5 second raster (the frequency at which Current and Voltage is available at).

Having created this table across the full data set, I could now extend the trip aggregation with a custom signal for kWh/100km - and also use the new custom table as the basis for kWh/100km in our device dashboard.