Log UDS data
UDS (Unified Diagnostic Services) is a protocol often used in automotives, incl. electric cars.
For details on collecting UDS data, see our UDS intro - below we recap the basics.
Table of Contents
Configure your device
To request UDS data, you need to know what CAN request frames to send. In contrast to OBD2, this is proprietary information and thus only known if you are the OEM or if the information has been reverse engineered.
In our EV data pack, we provide Configuration Files that may be used for the following EVs:
- Nissan EVs (e.g. Nissan Leaf)
- Hyundai/Kia EVs (e.g. Kona, EV6, Ioniq)
- VW EVs (e.g. ID.3, ID.4, Skoda Enyaq Audi Q4)
For UDS requests, you typically need to send a ‘Single Frame’ (SF) request followed by a ‘Flow Control’ (FC) frame to trigger a multiframe response from the vehicle. This can be done as illustrated in below picture, where the Flow Control frame is delayed slightly vs. the Single Frame:
Request and record UDS data
To record the UDS data, see the section on OBD2 data (the principles are the same). As with OBD2 logging, we recommend ensuring that you do not transmit data while the vehicle is powered off - e.g. by setting up a control signal.
Analyze and plot UDS data
Since UDS data often consists of multiframe responses, you need a software that is capable of reassembling the frames. This can be done with our Python API - meaning that you can e.g. visualize your UDS data in Grafana dashboards as per our playground examples. Our Python API and dashboard integrations describe how to perform UDS decoding via their README files.
As with the requests, the DBC files for decoding UDS data are proprietary. However, the aforementioned EV pack contains DBC files for a number of vehicles. If you need to perform UDS DBC decoding as an OEM, you can take outset in the structure of one of these DBC files to create your own (leveraging the extended multiplexing logic that is also used in OBD2 decoding).
