Preparing automotive logs

Use this guide if you’re debugging a vehicle ECU, IVI head unit, digital cluster, ADAS module, or telematics control unit: CAN bus errors, VHAL property failures, AAOS crashes, BSP integration issues, OTA regressions.

Accepted log types

  • AAOS bugreports: .zip from adb bugreport on Android Automotive head units. Same format as mobile Android.
  • VHAL / CarService dumps: dumpsys car_service, dumpsys vehicle_hal_v2_0, and similar text dumps that capture vehicle HAL property events.
  • Kernel / BSP dmesg: kernel ring buffer for device-tree issues, thermal events, and driver probe failures.
  • DLT traces: .dlt files and their .dlt.gz rotations, the AUTOSAR logging standard. Decoded into log lines that keep each message’s ECU, application, context and level, so you can filter on them like any other structured log. Control messages get their own CONTROL level, and a message sent without its text shows its message id. When the trace holds an ECU’s answer to a software-version request, that version is recorded for the ECU.
  • QNX system logs: SLOG2 / slogger2 text output, read as a structured log with its own severity levels.
  • Vendor board captures: a dumpstate_board archive of the head unit’s DLT traces, QNX logs, network captures and system traces, whatever extension the vendor gave it. Analyzed as a bundle: each log inside gets its own analysis, and a screen capture found in the archive is shown on the dashboard.
  • CAN bus traces: text output from the open-source candump tool, Vector .asc exports and .blf recordings, and DTS .trc traces. All upload as they came off the tool.
  • DBC files: uploaded separately through the References library in the console (not as a log). Once registered, your traces are decoded against your DBCs automatically. What a DBC decodes is shown only inside your organization, so an investigation of a decoded trace has no public link.

DLT and CAN analysis need the automotive log analysis capability on your account. See Why was I limited?.

For the full accepted/rejected list, see Supported file types.

Capturing CAN traces

candump (Linux SocketCAN): supported directly

If your bench or test rig runs Linux with SocketCAN:

# Bring up the interface (rate depends on the bus you're on)
sudo ip link set can0 type can bitrate 500000
sudo ip link set up can0

# Capture in logfile format (timestamped, machine-readable lines)
candump -L can0 > can0-trace.log

Upload can0-trace.log directly. Pair it with the relevant DBC file in the References library for decoded signal names. CAN FD frames, remote requests and error frames are read as what they are; error frames appear only when the capture was set to receive them (candump’s error mask).

Vector CANalyzer / CANoe, PEAK PCAN-View

Captures from Windows-side tools land as .blf, .asc, .trc, or .mf4.

.blf, .asc and DTS .trc files upload as they came off the tool. No conversion, no renaming. Every frame and identifier is read, with its timestamp (a .blf carries wall-clock times; a .asc and a DTS .trc carry offsets from the start of the recording), CAN FD flags, remote requests and error frames (a DTS .trc has no error-frame record); pairing the capture with a DBC file in the References library decodes the signal names as usual. A very large recording is read up to a limit.

.trc files written by PCAN-View, and .mf4 measurement files, need a text export first. Two unrelated tools write .trc files. Open yours and look at the first line: [Description] means upload it as it is, a line starting with a semicolon means export it first. A .mf4 uploaded directly is refused with the export named; a PCAN-View .trc is text, so it is accepted and read as an ordinary log rather than as vehicle-bus traffic.

To export, save the trace and convert it with can-utils-compatible tooling (log2asc / asc2log, or a script that re-emits each line as candump). The accepted line format is the standard candump output:

(1714820100.123456) can0 18FEF100#FFFFFFFF7DC8FF00

Capturing AAOS device logs

The same adb flow as mobile Android. From the head unit:

adb bugreport aaos-bugreport.zip
adb shell dumpsys car_service > car_service.txt
adb logcat -d > aaos-logcat.txt
adb shell dmesg > aaos-dmesg.txt

For full Android capture details see Preparing Android logs.

Needs a text export first

Without one these are not read as vehicle-bus traffic; what happens to each is under Capturing CAN traces above:

  • PEAK PCAN-View: .trc
  • ASAM: .mf4

Example questions to ask

Ask from the Research tab once the file is analyzed. Reach for Quick Search when you already know what you’re after, Deep Research when you need the root cause.

Quick Search for fast, cited lookups:

  • “Show all VHAL property changes around the navigation crash.”
  • “Which ECUs are transmitting?”
  • “Show messages on CAN ID 0x1A0.”
  • “Show the frames around the DTC.”

Deep Research for multi-step root-cause investigations:

  • “Why did the IVI reboot at 09:14?”
  • “What caused the VHAL timeout on PERF_VEHICLE_SPEED?”
  • “Correlate the CAN bus errors with the AP-side kernel events.”
  • “Trace the fault that set the diagnostic trouble code.”
  • “What preceded the bus-off event before the cluster went blank?”

Deep Research also reads each CAN identifier’s own timing, gaps and changing bytes, computed from the trace, so a question about a silence or a rate change can be answered without a DBC file.

See Quick Search and Deep Research for how the two modes differ.

Next

  • Deep Research: cross-ECU investigations across CAN, VHAL, dmesg, and logcat in a single report.
  • Delta Comparison: compare a passing build against a failing one across the same ECUs.
  • Quick Search: fast lookups when you know the CAN ID or the property name.